Well it appears to be the case for our customers when analyzing logs and symtoms.
As part of the login process to our app the user has a unique registrationId that server side connects the apps device to the user account.
The full details of the login process is irrelevant for the problem, the important thing is that for this to work the user registrationId must be recognized by the server and deemed active.
If the user uninstalls the app and installs it again it will get a new registrationId from the server and server side this mapping is stored in a db table, simplified:
| accountId | registrationId | deviceInfo | pushNotificationId | created | deleted |
|---|---|---|---|---|---|
| a1 | r1 | samsung SM-G900F | p1 | 2020 | 2021 |
| a1 | r2 | iPhone 12 pro max | p2 | 2020 | 2021 |
| a1 | r3 | samsung SM-G900F | p3 | 2021 | null |
| a1 | r4 | iPhone 12 pro max | p4 | 2021 | null |
Again simplified the deleted column is used to determine what devices to send notifications to.
In the app the registrationId is stored in SharedPreferences in MODE_PRIVATE and on an update of the app the registrationId is kept unchanged(at least it used to be).
SharedPreferences.Editor editor = context.getSharedPreferences(FondguidePreferences.class.getSimpleName(), Context.MODE_PRIVATE).edit();
editor.putString("registrationId", "r3");
editor.commit();
So, to the problem at hand. What suddenly happened after the latest release where targetSdkVersion was bumped from 30 to 31 and Java version from VERSION_1_8 to VERSION_11 is that thousands of customers apps suddenly started to call the server using an old registrationId that is marked as deleted server side and had not been used in years and therefore the login process is interrupted and the users cannot access the service.
We can see in our server logs and audit logs that, if we use the db table as example, user with account a1 has initiated login using the registrationId r3 from her samsung(and occasionally r4 from her iPhone app) hundreds of times during the years 2021-2023 so if r3 was not correctly stored in SharedPreferences this would not have been possible.
During that time the app has been updated several times without problem and r3 has still been fetched from SharedPreferences and used for initiating login.
Then all of a sudden after updating to the latest app version last month the samsung reverted back to using r1 to initiate login. The iPhone version of the app still uses the latest though(r4). We do not use flutter or similar so the two code bases are very different but only the android version suffer from this.
So given what we see it seems that after updating, the app suddenly has gotten hold of the oldest version of the SharedPreferences but how is that even possible?
As far as I know there is no versioning of the /data/data/ourapp/shared_prefs/ourapp.xml where old values could be stored?
I have seen for instance this thread SharedPreferences are not being cleared when I uninstall but our customers has just updated their apps and not uninstalled/installed(if they had there would be a new entry in the table with created=2023). And even if they did why would the SharedPreferences from 2020 be picked up from any backup and not the latest that has been in use for years?
Perhaps something similar to SharedPreferences lost after app update but here the settings are not completely lost which in our case actually would have been a lot better as that would mean a new registrationId would have been created(as it would appear as a new install to the app).
As we have no idea what is wrong, so far we have simply made the old registrationIds valid to initiate login with as well as the new ones. So most users can now login although there are cases where old devices, and thereby registrationIds, have been deleted from the database(for instance for GDPR reasons) so in those cases the user is not recognized by the server at all and can not login as the device cannot be mapped to an account to fetch further login information from.
Any ideas of what may have happened are greatly appreciated!
