[JingMatrix]

/data/resource-cache has been shadowed in the daemon's mount namespace since LSPosed/LSPosed#1627 of February 2022, whose entire justification was "to avoid overlay conflict". Nobody wrote down what that conflict was, which is why the line was dropped in 156c6ae and restored the next day in 3c020a9 on a suspicion that could not be confirmed. This records the reason and keeps the shadowing, but pays for it with a mount that leaves nothing to count from outside the namespace.

The daemon is a root app_process, and it initializes framework assets twice over: once through ActivityThread.systemMain(), which builds a system context, and once through the AssetManager behind FileSystem.resources, whose public constructor and Resources.getSystem() both land in createSystemAssetsInZygoteLocked. On Android 11 and later that method asks OverlayConfig for the immutable framework idmaps. The comment on createImmutableFrameworkIdmapsInZygote says only the zygote may invoke it, and nothing enforces that: it forks idmap2 create-multiple, which writes into kIdmapCacheDir, that is /data/resource-cache, through a plain std::ofstream with no lock held.

The zygote reaches the same code from preload() by way of Resources.preloadResources, and only creates /dev/socket/zygote after preloading has returned. A daemon running alongside it therefore derives the same idmap paths and can truncate the file the zygote is writing, which is the overlay conflict of #1627; the up-to-date check that normally makes the second writer a no-op is no help while the first writer is still mid-file. On Android 10 and earlier the same entry point instead read /data/resource-cache/overlays.list and raised IllegalStateException when a listed idmap failed to load, so a list left behind by the previous boot could take the daemon down before it started.

That window has been narrow since LSPosed/LSPosed#1748 added the wait on the zygote socket, and narrower still now that service.sh is the only launcher. The daemon nevertheless forks idmap2 on every start and writes whatever the directory it is shown happens to lack, so the shadowing stays.

What does not stay is the tmpfs. A filesystem with no block device draws its dev_t from one kernel-global pool: get_anon_bdev() returns the lowest free id and holds it until kill_anon_super() releases it. The live set is dense from below, so a minor missing from a process's own mountinfo is not a free slot but a superblock that is alive and invisible from there, including one mounted only in a daemon's private namespace, which no per-namespace check can reach. A tmpfs over /data/resource-cache is exactly such a superblock, and the gap it leaves is readable by any app on the device: JingMatrix/Demo@1f91ee6. A bind mount allocates no dev_t at all, since it reuses the superblock of its source, so binding an empty directory of our own hides the cache just as well while allocating nothing. The directory is wiped and recreated on every start, so the idmaps regenerated inside it do not accumulate, and the daemon keeps its framework overlays as it did before.

The change is one file, zygisk/module/daemon: mount tmpfs -t tmpfs /data/resource-cache becomes a bind mount of $dir/.resource-cache, with the reason for the mount written above it.