I’ve been searching for this, but have ben unable to find the answer - apologies if I missed the answer somewhere.
Will the new Jolla phone (with sailfish OS preinstalled as I understand it) be shipped with locked bootloader? I ask because in my experience, the unlocked bootloader often makes government apps unable to run.
I currently run e/os with MicroG, and find 99% apps working, but government apps, like Danish MitID and Driving Licence app detect both root and bootlock status (better than many apps, e.g. banking apps).
Firstly; fixed your title. If every question was just called “question”, how can you tell them apart?
Secondly - and this has been answered many times before - what android in the AAS container sees or thinks about the bootloader has nothing to do with the real bootloader lock status. As such i don’t imagine that changing from the current status of those apps (there should be some threads about them).
The Android stuff runs in a container, not really in the actual OS.
The headline was a typo on on my part- thank for fixing it!
Yes I was unsure about the terminology here, I use Linux on my laptop, but i’m not tech savy at all.
But when the app that runs in AAS look for bootloader status or “root” status, what does it “see” then;
does it see the underlying Linux environment “root” and “bootloader” status (i’m using these terms likely incorrectly, as I don’t know what/if they’re called in the Linux environment), or
are they just getting no answer at all, thereby also failing the integrity check
I don’t claim to have all the answers.
But for a lot of it; it sees what you want it to see.
Not everything is as easy as just lying to it though - cryptographic chains of trust and whatnot.
microG generally only deals with slightly higher level stuff like SafetyNet APIs.
Edit. Have to admit that I also thought that it would affect AAS side, but nice learn the true state of things. Even when it isn’t the pleasant answer I was hoping for
Interesting how different people have different mental models. For me it seems so obvious; what would be the point of a container if anything inside could arbitrarily inspect the host?
I’m not sure this is better of worse. Even if the real bootloader was locked; would it be in such a way that Android accepts it? Having full control, without having to mess with the actual OS, spontaneously sounds better and more workable to me.
Well for me the container is still kind of mysterious thing. For me it is up mainly as there can’t be two OS running simultaneously (according to my knowledge). But the more I understand the more sense that does.
Don’t know, I just thought same as the OP. More android apps would work.
Again - please forgive my inability to use correct technical terms, and also forgive my possible misunderstanding of the exact architecture of the way AAS runs in the Linux environment. However, I was assuming the following:
An android app running may want to know, if it is fact running in an android environment which has root access and/or if the bootloader on said android system is locked or not.
There are 3 answers to those questions - yes, no, unknown. Would the AAS not be able to provide some sort of answer to the app? Or would AAS’ potential access to such information breach the “sandboxed” principle of the AAS, leaving a backdoor of some sort open for a malicious app running inside AAS?
I think those questions are oversimplifying - it depends a lot on what is in fact involved in doing these checks.
Apps too oversimplify their feedback to users, if they even say something.
Generally it could just tell the software running inside the container whatever it wants to hear. And as far as i know, it does as much as it can. But of course apps will also up their game trying to understand when being lied to - or they just freak out when something doesn’t fully meet their expectations. Some apps are happy, some are not.
There is generally no need to hook it up to the real status of the phone for the faux security lock-in aspects - honestly please stop suggesting it or bring arguments for why it makes sense.
The point is that if Android in AAS could “just check the real status” - without being explicitly allowed we have an issue, because then it could do however many other things requiring similar access too.
Hopefully someone else will answer to your question