I didn't realize Android verified apps on boot. I had a silly patch for Twitter (done by directly hexediting one of the overlay APKs on-device, because I'm lazy) and it worked fine until I rebooted, then Twitter disappeared.
Or is this some Play Services verification thing?
Conversation
I'm kind of surprised because doing a full sig check on every app on boot would probably take quite some time, and Android boots pretty fast these days. Or maybe the file mtime tipped it off?
6
42
Replying to
Play services doesn't do anything like that. You changed the apk so it couldn't use the cached data and sent it through the package manager again. It could skip the signature checks when it's in a verified image. System apps and APEX components can be updated via userdata though.
1
10
APEX components are a filesystem with Android Verified Boot including dm-verity inside of an APK container. That's what enables updating arbitrary things out-of-band instead of simply APKs.
1
4
source.android.com/security/apksi provides a form verified boot for normal APKs but there's no reason for it to be used for APKs in OS images since regular verified boot covers them. The purpose of that is always verifying all data read from them since normal APK signatures are too slow.
2
4
Replying to
So you're saying it was in fact the mtime that triggered it to go through the package manager again while checking the caches.
1
Replying to
It would usually be triggered by versionCode being incremented since metadata inside zips and the filesystems would usually all be normalized so the only thing to trigger this is versionCode or a new OS version. I think mtime would trigger it, just not normal outside userdata.
1
Replying to
Yeah, mtime invalidates the cache in that case since it can't assume that versionCode means it's the same thing
It doesn't disallow installing an update with an equal version code and it's common to use it for development.
Time would invalidate at least most of those caches.
There are likely certain things it only does when actually installing an update via the package manager but it's meant to avoid indefinitely trusting persistent state.
It doesn't regenerate this stuff every boot but it does redo nearly all of it after an OS update.
1
1
It's interesting since it has security implications. It would be best for security for this stuff not to be cached and for it to completely relabel userdata with fresh SELinux labels based on paths every boot, etc. In practice, can only get away with that stuff after OS updates.
1