Ensure users set buildNumber / buildDateTime when they try to OTA / sideload (if not just using tagged releases)

[Atemu]

With the most recent µG update, I got struck by this bug again but it has happened a lot in the past.

The /system/data/appcache becomes stale which causes µG to be displayed as the previous version in settings, have weird names (random strings used in µG), crash and generally not work well.

Wiping the appcache makes µG work again without issue.

[danielfullmer]

Just curious, how are you updating microg? I haven't encountered this issue.

[Atemu]

I updated it by installing an ota zip containing a newer µG version. This is on LineageOS 18.1 of course, forgot to mention it.

What does the appcache do though? Because a workaround would be to simply wipe it on zip installation.

[zhaofengli]

I recommend bumping your buildDateTime for every build you make. A different buildNumber (generated from buildDateTime by default) will cause the caches to be cleared automatically and avoid issues like this.

[Kranzes]

This should do it: sed -i "s/buildDateTime = mkDefault .*/buildDateTime = mkDefault $(date +%s);/" flavors/lineageos/default.nix

[danielfullmer]

@zhaofengli is right. Every time I push a new build to my local device that isn't a tagged release I set buildDateTime. https://docs.robotnix.org/modules/ota.html mentions setting buildDateTime, but we should make that instruction more prominent.

---

I've had an idea to make this less likely to affect users: Set the type of buildDateTime to a custom one which has modified merge functionality, Have the merge function just return the maximum of the values to be merged. Then, in each module that could substantively affect the build, set the default buildDateTime to the current datetime in each commit that makes a nontrivial change to the module. Then, if the user doesn't set buildDateTime themselves, it'll still be the maximum of all the recent upstream changes that affect the build. The downside of this is likely just the hassle of updating the buildDateTime for each module. Feedback on this proposal is welcome.

[Atemu]

It'd be nice if there was a build ID that was used to determine whether caches need to be cleared because we could just plug the drv hash into it to automatically get a new ID when the image is different (by Nix' definition).

Though tbh, we could also just assume that every robotnix build is different to always cause wiping of caches and the like. The only optimisation we'd lose there would be in the case of installing the same image again but I don't think that's a particularly likely scenario. (And should you need to do that, you probably also want to wipe caches etc.)

I think this is a serious issue we need to think more about, could this be re-opened?

[danielfullmer]

It'd be nice if there was a build ID that was used to determine whether caches need to be cleared because we could just plug the drv hash into it to automatically get a new ID when the image is different (by Nix' definition).

IIRC some apps (Google's I think), actually parses the BUILD_NUMBER as an integer--which was the reason GrapheneOS (and consequently robotnix) stopped including the periods in the YYYYMMDDhh tags and build numbers. Like, the buildDateTime, if we want to have build number be an integer, it should probably be monotonically increasing.