I don’t quite understand the essence of these errors, but if this is an attempt to open these files, then there will be errors, because updating to version 00.01.02.00.02 deletes all .lic files as they are no longer valid due to the changed option generation algorithm.
I am wondering if the new RKey.data method parks a unique key onto each system, perhaps used by Rigol later in some way to gen new lic files? Now each device becomes unique in some way, hence my key won't gen lics for your device, as we have done before with a common tool. However, knowing the method can still yield good lic files, but the key used for each system is perhaps different.
There's perhaps a test to find out.
Maybe take v01.02.00.02 GEL, unpack the files into a "orig" folder, install the GEL to the device, then use the device script to re-GEL a backup, and then find the file diffs between the two. This should show us what the new FW did during it's install and 1st boot?
Then perhaps take md5 of all the files from this 1st backup. Then restore something like v01.02.00.00 to the device, then update device with v01.02.00.02 again, grab a GEL backup, and repeat the compare steps again.
Now you have two lists of md5, one from backup #1 and one from backup #2.
Now find all files that have different md5. Then analuze that to determine if you expect such file to have same or different md5.
This method might lead to knowing of this new key method creates unique key during the FW install/boot, or not. Might also help find more info about the key itself.
The 2nd method which seems perhaps doable, mod the APK and re-sign it so it runs as shared user "system". Then we can muck around with functions and what-not, bypass the new key methos, etc.