The error message after 10 seconds still comes back, though, so I have to tap the app I’m looking for fast enough.
I have also tried (several times) to ‘clear storage + cache’ of the App Lounge but that doesn’t help.
My device is FP3 with /e/OS v1.14 stable, are there any other people with the same/other device also having this problem? Then maybe I can create an issue on Gitlab.
(another reason for app-list returns to differ is how getAppFilterLevel()[1] behaves, for example with apps and geo-restrictions, but this is not what you post is about)
Are /e/ still using cleanapk.org? I thought the whole point of implementing App Lounge in place of Apps was to get away from that completely anonymous and un-transparent web site, owned and operated by some unknown organization (that uses the same hosting provider as /e/ Foundation).
If they are, that’s another very good reason to use F-Droid and Aurora Store
@petefoth hijack the thread topic with cleanapk? the only issue with apks is trust on first use, not beyond - and you can verify that with mirrors publishing past signature hashes (cleanapk doesn’t in their api last I checked sadly but you can compare to mirrors that do).
The appstore client most likely uses gplay directly for corpus, availability and being up to date at all times. I’m amused how you’re still puzzling the cleanapk schpiel
The issue is not with the apks, it is with the fact that /e/ is still using cleanapk.org 18 months after we were told (in March 2022) that
CleanAPK is still going to be used momentarily for the catalog of apps coming from F-Droid and Progressive Web Apps, ***but will be totally abandoned this year. ***
I’m not amused: I am concerned that this issue has not been fixed 16 months after the release of /e/ v1.0 and more since the first release of App Lounge
But you are right, I have hijacked the thread, and for that I apologise. I will start a new thread to try and find out why /e/ is still sending their users ip addresses to a completely anonymous web site.
I have the exact same problems as you with 2 phones ( one S10 with 1.14S-dev and one S7 with 1.12Q-stable). i tried to fixed theses issues with the same remedies as you without succes.
I didn’t find any complains in GitLab concerning these problems…
I hope that will be fixed in a futur releases !!
yep nice improvement and might just fix the behaviour that you lamented. Pagination replacing fetch-all helps to limit amount of API calls - thus not exhausting that gplay auth token pool as quickly.
cleanapk is supplying the exodus / privacy scores and foss apks / pwa. So a fallback to cleanapk wouldn’t contain for example the temu app in your first screenshot (they don’t have it) - it must be an incomplete response by gplay then before rate limiting kicked in.
I also have issues with AppLounge very often not finding apps. Recently: tricount, MosaLingua… I enter the full name in AppLounge search bar and there is no result. I do the same in Aurora Store and the apps are found immediately. I have to go to the Android apps management and clear local storage of AppLounge and restart the app (I have then to re-accept the Terms of Use) and then AppLounge finds the apps immediately.
So there is some sort of cache issue.
or just exhausted token pool to ask gplay apis with your (even exact) appids, this is why cache purge helps, you get assigned a new token that isn’t rate limited.
