I have android 13 and latest and f-droid 1.19.1. i have to manually tap update and then install after
I do not have gapps installed and i thought this might be the issue
What is gapps, some open source component, library, app? No? Then no, it’s not needed.
Jokes aside…
If you are on Android 12 or later, and not on a Xiaomi device, then autoupdates should just work.
Be sure to slide both Wi-Fi and mobile data all the way to the right.
Be sure to turn both “auto” toggles in Settings.
Also do update to 1.20 just to be sure, expand Versions… 
1 Like
read more in Unattended updates for everyone, 1.19 is here | F-Droid - Free and Open Source Android App Repository
and One new, one broken, one beta, more updates | F-Droid - Free and Open Source Android App Repository
and Reaching targets and mixed locales | F-Droid - Free and Open Source Android App Repository
1 Like
It is the xiaomi issue. I thought i was not affected because i dont use xiomi OS
My bad… Thanks for answering… Ill go back to the privileged extension
If you’re not on stock, it would not be an issue.
Please note that F-Droid must first update an app at least once, the app also must have a recent targetSdk as well.
See the linked issue, detection is still faulty, feel free to propose a better way, many users would like that to be enabled 
1 Like
@Licaon_Kter
oh rip
I gave it a shot SessionInstaller: refine Xiaomi check (!1397) · Merge requests · F-Droid / Client · GitLab
2 Likes
maybe a notice in settings could alert the user about the reason it cant autoupdate (either target sdk, bug, at needs the app to be updated once, etc…)
I think i updated the app several times since the update (i picked a frequently updated app for the test)
Damn, Xiaomi’s gotta be Xiaomi. Just a few days ago, I had to disable per-app local settings on my apps because, well, Xiaomi broke that as well… fix: Disable app locale setting on MIUI due to Xiaomi's broken implementation by starry-shivam · Pull Request #133 · Pool-Of-Tears/GreenStash · GitHub
we know SessionInstaller: refine Xiaomi check (!1397) · Merge requests · F-Droid / Client · GitLab
Replying to this:
parsing hundreds of props may be slow and can also cause selinux denial spam
You won’t get SELinux issues because, first, you’re not parsing “hundreds” of properties, and second, these are public properties located inside build.prop, which anyone can read without any special permission. You can also manually check it by running getprop ro.mi.os.version.name in termux. Afaik, I haven’t seen any AOSP/Lineage-based custom ROM having this property because it essentially translates to the version of MIUI running on the device, which doesn’t make sense in AOSP custom ROMs. However, these properties are present in MIUI-based ROMs like Xiaomi.eu or MIUI Elite ROM, etc.
@starry
yep, you are correct
not sure wtf I was referencing
I thought I saw a gist run getprop and parse the output.
And I did just make a test app and there were indeed no denials.
the same idea however was turned down months ago anyway however F-Droid basic debug doesn't update apps automatically on Xiaomi Mi phones (#2659) · Issues · F-Droid / Client · GitLab
1 Like
the package check method however does appear to be much faster fwiw: SessionInstaller: refine Xiaomi check (!1397) · Merge requests · F-Droid / Client · GitLab
1 Like
What’s the package check method? Can you share the code or any link?
Honestly speaking, I don’t think caring so much about a few milliseconds makes much sense here. At least in my testing, it used to take 20ms on average to execute. Yes, it might not be very “fast” because it reads two different properties: first to figure out if the device is running MIUI, and then to determine whether it’s running HyperOS (Xiaomi’s new OS after MIUI 14). In my use case, I use it inside an onClick() callback in one app, and inside a remember variable in another so the function doesn’t get called on every recomposition but only once when the screen is rendered. I honestly don’t think anyone is going to notice an extra 20ms to process the click event and show an appropriate message if the device is running MIUI and hence doesn’t support some of the functionalities present in standard Android APIs.
However, they will indeed notice if their device is capable of supporting it but the functionality is disabled anyway based on the assumption that all Xiaomi devices will have it broken. FYI, the per-app locale API which I mentioned earlier is broken in MIUI but seems to work perfectly fine in HyperOS, so I don’t want to disable this function on the assumption that it will take 20ms more to execute, because in the real world, no one can really tell the difference of 20ms (it’s basically 0.02 seconds).
On another note, I’m not very familiar with the session-based installer API being discussed here, so I can understand if the implementation may vary from my use case and speed might matter more in this scenario. Although, even in that case, you can cache it inside a singleton object and basically call it once on app launch, then reuse the returned information throughout the app’s lifecycle. You could even make it persistent with a timestamp, like 1 week or 1 month, so it doesn’t query it again for the said duration.
already linked several times above SessionInstaller: refine Xiaomi check (!1397) · Merge requests · F-Droid / Client · GitLab
1 Like
I see. (not very familiar with the GitLab interface), anyway, it seems like a good enough solution, though there may be false positives in some cases as the other person mentioned. However, I would suggest (if possible) checking if the session-based installer API works on HyperOS because MIUI is now an EOL OS, and HyperOS has fixed many broken standard APIs compared to MIUI. If it’s still broken on HyperOS, then this package query-based check should be sufficient.
Btw, you should add POCO (A sub brand of Xiaomi, like Redmi) too, in the following check:
if (isStockXiaomi == null) {
boolean xiaomiPhone = "Xiaomi".equalsIgnoreCase(Build.BRAND) || "Redmi".equalsIgnoreCase(Build.BRAND);
}
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.