Android App does not persist accessories across restarts

[alexhorner]

I have installed the APK on my device and successfully imported my JSON files for my devices. I am able to get locations for my devices after pointing the app to my server's Macless Haystack URL.

If I close and re-open the app (fully close it from the task switcher) all of my accessories have completely disappeared and I have to import them again. Additionally, the Show this devices location switch seems to remember the last state it was set to (in my case, off) but is completely ignored and needs to be turned on and off once again to hide the device location after an app restart.

I haven't changed any other settings from the default except the URL (which works fine), so don't know if they have persistence issues too.

[supaeasy]

Cannot confirm. Just updated the app and devices do persist. Latest stable Android on Pixel 7

[dchristl]

Hello,
do you have the possibility to look into the Android log (adb logcat). If so, then there should be problems with access. Which device do you have and which firmware (custom Rom? ) is on the device?

[alexhorner]

I'll see if I can hook into logcat, been a while but I'll take a look and report back.

Samsung Galaxy S22 Ultra with stock ROM

[alexhorner]

Here's a logcat which should be clear of any personal data. I only needed to redact the JSON name, hopefully nothing else in there. It's on Pastebin so that it expires after a week https://pastebin.com/uErkUyLA

[KUKHUA]

Happens to me too. The accessories disappear after I close it. This is after importing a new one from JSON.
Reverting to the previous version of the application fixes this.

[dchristl]

Unfortunately, I can't see anything in the log that indicates an error. Unfortunately, neither of you mentioned the Android version (15?).
Maybe there is a bug in one of the libraries, I have updated it. You can find the updated version in the attachment.

android-application.zip

[alexhorner]

@dchristl That appears to have fixed it, thanks! I have noticed one other issue which I can raise as a separate issue if you'd like?

When opening the app, it does an automatic refresh of locations for accessories. This appears to fetch all data judging by the count it displays, but seems to select a much older location entry to show the time and location of. If I manually refresh with the button it shows the latest. Almost as if the automatic refresh has the sorting wrong or something when it selects which location report to display.

[dchristl]

Great to hear that. I will put it the change in the next release.

Your second problem is known, but unfortunately I still have no idea how to solve it. The procedure is that all locations are picked up. These are encrypted and it takes a relatively long time to decrypt them (several minutes depending on the device and number of tags). Therefore, the most recent report is decrypted and displayed at Apple first. It then continues with the rest in the background. The most recent location is only updated once all of them have been decrypted.
The main problem here is that the most recent report refers to the time of transmission and not to the time at which the coordinates were recorded. The correct time (of the coordinates) can only be determined after complete decoding. This is done so that the user does not have to wait x minutes for his current coordinates. I have already optimised this several times at this point and the offset should already be smaller, but it is not yet perfect.
The manual refresh is not actually necessary (it has no function as long as decryption is still taking place anyway), you would simply have to wait here and in a large number of cases the last transmitted report is also the one with the last coordinates/the most current one.

[alexhorner]

@dchristl I'm android 14 by the way.

Is there any reason not to cache the locations locally and possibly also hash them, so instead of decrypting them every time you compare hashes to the already decrypted versions and just retrieve those from cache?

[dchristl]

That is one of the improvements I already have done 😉 But if the last submitted report is not the last location, you have always this issue. But wait until the next report and the problem should be gone.