com.android.networkstack.inprocess.overlay Copy

A Runtime Resource Overlay (RRO) whose name pairs it with the in-process build of Android's network stack. It is configuration rather than an app: an RRO changes the resource values of a target package at runtime without altering the target's code. In this site's sample it has no launcher entry in any observation, is between about 8.5 KB and 16.7 KB in size, and is labelled NetworkStackInProcessResOverlay on most devices and NetworkStackOverlayGo on a few. The in-process network stack is an AOSP build variant. Alongside the updatable NetworkStack module, the NetworkStack source defines InProcessNetworkStack, described in its build file as a "non-updatable network stack running in the system server process for devices not using the module". It is a replacement for NetworkStack, is signed with the platform certificate, and its manifest declares the package name com.android.networkstack.inprocess running in the system process. The AOSP change that made it override NetworkStack explains the purpose: it avoids shipping both APKs on Android Go devices. This overlay's package name is that package name with ".overlay" appended, which is the same naming pattern as com.android.networkstack.overlay documented separately on this site, so the natural reading is that it carries a build's NetworkStack configuration for the in-process variant. That is an inference from the naming: this site records a package's own name rather than the target declared inside its manifest, so what a given copy targets cannot be confirmed from here. The values an overlay of this kind may set are those in the module's NetworkStackConfig overlayable, such as the captive portal probe URLs and the default DNS servers used by the DHCP client. Version note: the in-process variant does not exist on every AOSP release. InProcessNetworkStack and its manifest are present in the android15-release branch of the NetworkStack source and absent from the android16-release branch. This overlay is nonetheless observed here on devices from API 30 through API 36, with version names running from "12" to "14". Whether a copy seen on a newer release still has a target to configure, or is simply carried forward in the device image, could not be sourced. Where signer data is recorded here, every key is classified as an OEM key that also signs the framework on its device (Motorola, Xiaomi, vivo, OPPO, NUU and ANT DAO Technology), which fits an overlay built into each device image, and the sample is weighted towards budget and ODM-built hardware. The only permission it declares is POST_NOTIFICATIONS, which a code-free overlay has no obvious use for; no source consulted accounts for it. For Android Enterprise, EMM and kiosk use it has no role in enrolment or policy. Removing it does not harden anything: on a build that uses the in-process stack it would remove the build's connectivity configuration and could affect network validation and captive portal detection. Leave it in place, and manage captive portal behaviour through EMM application policy instead.

• NetworkStack module - Android Open Source Project →
• Change the value of an app's resources at runtime (RROs) - Android Open Source Project →
• NetworkStack Android.bp, InProcessNetworkStack (android15-release) - Android source →
• NetworkStack AndroidManifest_InProcess.xml (android15-release) - Android source →
• NetworkStack Android.bp (android16-release) - Android source →
• Have InProcessNetworkStack override NetworkStack (frameworks/base commit) - Android source →
• NetworkStack overlayable.xml (packages/modules/NetworkStack) - Android source →
• Package provenance for com.android.networkstack.inprocess.overlay - Android System App Database →

• Re-signed by each device maker with its own platform key - 7 different certificates appear across 6 device makers in our sample. That is the signature of a stock AOSP/system package every OEM builds and signs itself, not a single maker's or a third party's preinstall. These are platform-level keys: they also sign the Android framework itself.
• Its largest observed manifest declares 1 permissions: 1 runtime (user-granted).
• Never reported as user-facing, so it runs as a background or system component rather than an app the user opens.