Every time I update the daily Android version (foss-debug version), I always get a prompt that the new version has a different signature from the installed version, preventing direct over-installation.
The actual steps I need to perform are:
Back up the current account data;
Uninstall the installed version and select to clear all data during uninstallation;
Install the new version;
Restore the backed-up data.
So, can the same signature be used when upgrading the version? That would make the upgrade process more convenient.
Why do I need to clear the data while uninstalling? Because once I uninstalled the old version without clearing the data, the new version still couldn’t be installed successfully, prompting a signature inconsistency. At that time, I was confused. To solve this problem, I tried each version package one by one until I successfully locked the version with the same signature, installed it, uninstalled it, and deleted the data, only then could I install the new version. I don’t encounter this issue when installing other software, so I don’t quite understand why.
This happens because the nightlies (that’s what the daily Android version is called) are built automatically on a CI server, which does not have a stable key. This could be changed, but we unfortunately don’t have the capacities to do so.
Either you’re installing the releases of the other software (rather than nightlies) or they are a bigger team and have someone to put in the effort that the key is saved and re-loaded.
Thank you very much, I understand now, I think I can use the stable version. Additionally, if I compile the Android version myself (as per the development documentation, it is compiled in a Docker container), is there a way to maintain stable signing for multiple compilations?
So there are environment variables you need to set. I’d make a folder with the keys on the host machine, then mount it into the docker container via the volume option and set the env vars to point to the mounted directories. (I recommend looking at the docker documentation and maybe even using docker-compose to not deal with a super long docker run command).