Hi,
What do you think about this article from GrapheneOS’s blog :
4 Likes
If it’s on Android, longform prose by Graphene is good education. I enjoy reading it, but do not subscribe to the conclusion.
You can’t fix a broken industry by buying more of their products more often.
7 Likes
While I feel like this post is written by someone deeply knowledgeable about all the development ‘stuff’ (lacking a better word) I do not really think they are still in touch with what actual privacy concerns of average people are. But that is – from my understanding – the target audience for /e/OS. For most people, I would assume, blocking trackers is way more important than hardware level encryption (which is mostly a security concern, and only indirectly a privacy concern).
While I do not have the technical insight to really analyse what is said here and whether this is indeed as bleak as it is made out to be, there is one crucial point I’d like some answer from the dev team.
“/e/OS changes the UI displaying the patch level to one which masks what’s actually being provided. They also set an inaccurate Android security patch level ignoring the non-AOSP portion of the patches and part of the AOSP portion of the patches. /e/OS partially shipping the AOSP portion of the patches as providing the full monthly privacy/security patch backports, which isn’t what that is.”
This is said in the post. It is – like most statements – not really backed up by anything apart from claiming it. Is there anything to it and if so, is it as misleading and mischievous as it is framed or rather a quite conventional way of development the post author disagrees with?
7 Likes
As someone using custom ROMs since CyanogenMod I think GrapheneOS misses the point and is drawing scenarios that do not concern the “average user”. And they have to promote their system because due to Google’s strategy to cover Android and the Pixel phones behind a less frequent source update this is in a kind understandable.
Fixating on the timeliness of patches isn’t the point for me. To get a phone that does not track me on every step I take is. And where I can decide what Apps “leak” or do telemetry.
GrapheneOS is for the Nerd who does not care to use an American(!) phone in these times - which gets more and more undocumented and where the crucial hardware abstraction layer (which is fully documented by Fairphones hardware btw) is more and more difficult to reengineer.
So factually there may be some substance, but to make a phone more “safe” and less transparent GrapheneOS isn’t a) the ROM to use and b) the hardware to do it on.
Apps are the holes in the system, not the phone in the first place.
7 Likes
[Update] please read the post by the /e/OS developers
Let’s face it. There are many valid concerns. [Please correct my if I am getting this wrong]
1̶. D̶e̶l̶a̶y̶e̶d̶ a̶n̶d̶ I̶n̶c̶o̶m̶p̶l̶e̶t̶e̶ S̶e̶c̶u̶r̶i̶t̶y̶ P̶a̶t̶c̶h̶ D̶e̶l̶i̶v̶e̶r̶y̶:̶ /e̶/O̶S̶ i̶n̶d̶e̶e̶d̶ o̶f̶t̶e̶n̶ l̶a̶g̶s̶ (̶f̶a̶r̶)̶ b̶e̶h̶i̶n̶d̶ s̶t̶a̶n̶d̶a̶r̶d̶ A̶n̶d̶r̶o̶i̶d̶ a̶n̶d̶ i̶O̶S̶ i̶n̶ d̶e̶l̶i̶v̶e̶r̶i̶n̶g̶ m̶o̶n̶t̶h̶l̶y̶, q̶u̶a̶r̶t̶e̶r̶l̶y̶, a̶n̶d̶ y̶e̶a̶r̶l̶y̶ s̶e̶c̶u̶r̶i̶t̶y̶ p̶a̶t̶c̶h̶e̶s̶, i̶n̶c̶l̶u̶d̶i̶n̶g̶ O̶S̶ a̶n̶d̶ b̶r̶o̶w̶s̶e̶r̶ u̶p̶d̶a̶t̶e̶s̶. M̶a̶n̶y̶ c̶r̶i̶t̶i̶c̶a̶l̶, h̶i̶g̶h̶, m̶o̶d̶e̶r̶a̶t̶e̶ a̶n̶d̶ l̶o̶w̶ s̶e̶v̶e̶r̶i̶t̶y̶ p̶a̶t̶c̶h̶e̶s̶ a̶r̶e̶ n̶o̶t̶ p̶r̶o̶m̶p̶t̶l̶y̶ (̶o̶r̶ e̶v̶e̶r̶)̶ b̶a̶c̶k̶p̶o̶r̶t̶e̶d̶, l̶e̶a̶v̶i̶n̶g̶ k̶n̶o̶w̶n̶ v̶u̶l̶n̶e̶r̶a̶b̶i̶l̶i̶t̶i̶e̶s̶ u̶n̶p̶a̶t̶c̶h̶e̶d̶ o̶n̶ u̶s̶e̶r̶ d̶e̶v̶i̶c̶e̶s̶ f̶o̶r̶ m̶o̶n̶t̶h̶s̶ o̶r̶ p̶e̶r̶m̶a̶n̶e̶n̶t̶l̶y̶. T̶h̶e̶ l̶a̶t̶e̶s̶t̶ e̶x̶a̶m̶p̶l̶e̶ w̶a̶s̶ t̶h̶e̶ t̶r̶a̶n̶s̶i̶t̶i̶o̶n̶ f̶r̶o̶m̶ /e̶/O̶S̶ 2̶.8̶ t̶o̶ 3̶.0̶.4̶, w̶h̶e̶r̶e̶ m̶a̶n̶y̶ u̶s̶e̶r̶s̶ h̶a̶d̶ t̶o̶ a̶c̶c̶e̶p̶t̶ t̶o̶ h̶a̶v̶e̶ a̶ b̶r̶o̶w̶s̶e̶r̶ w̶i̶t̶h̶ a̶ s̶e̶r̶i̶o̶u̶s̶ s̶e̶c̶u̶r̶i̶t̶y̶ f̶l̶a̶w̶ i̶n̶ t̶h̶e̶ s̶t̶o̶c̶k̶ /e̶/O̶S̶ b̶r̶o̶w̶s̶e̶r̶ (̶a̶n̶d̶ W̶e̶b̶V̶i̶e̶w̶?̶)̶. B̶U̶T̶:̶ /e̶/O̶S̶ w̶a̶s̶ t̶r̶a̶n̶s̶p̶a̶r̶e̶n̶t̶ a̶b̶o̶u̶t̶ t̶h̶i̶s̶ a̶n̶d̶ t̶r̶i̶e̶d̶ t̶o̶ m̶i̶t̶i̶g̶a̶t̶e̶ t̶h̶e̶ i̶s̶s̶u̶e̶ a̶s̶ f̶a̶s̶t̶ a̶s̶ p̶o̶s̶s̶i̶b̶l̶e̶. K̶e̶e̶p̶ i̶n̶ m̶i̶n̶d̶ > 2̶0̶0̶ d̶i̶v̶e̶s̶ v̶s̶. f̶e̶w̶ d̶e̶v̶i̶c̶e̶s̶. U̶n̶l̶i̶k̶e̶ m̶a̶i̶n̶s̶t̶r̶e̶a̶m̶ A̶n̶d̶r̶o̶i̶d̶ o̶n̶ P̶i̶x̶e̶l̶ o̶r̶ i̶O̶S̶ (̶w̶h̶i̶c̶h̶ r̶e̶c̶e̶i̶v̶e̶ t̶i̶m̶e̶l̶y̶ u̶p̶d̶a̶t̶e̶s̶, e̶v̶e̶n̶ f̶o̶r̶ l̶o̶w̶e̶r̶-̶s̶e̶v̶e̶r̶i̶t̶y̶ i̶s̶s̶u̶e̶s̶)̶, /e̶/O̶S̶ o̶n̶l̶y̶ p̶u̶s̶h̶e̶s̶ p̶a̶r̶t̶i̶a̶l̶ o̶r̶ d̶e̶l̶a̶y̶e̶d̶ b̶a̶c̶k̶p̶o̶r̶t̶s̶, a̶n̶d̶ s̶e̶e̶m̶s̶ t̶o̶ m̶a̶s̶k̶ t̶h̶e̶ “r̶e̶a̶l̶i̶t̶y̶” b̶y̶ a̶l̶t̶e̶r̶i̶n̶g̶ t̶h̶e̶ d̶i̶s̶p̶l̶a̶y̶e̶d̶ p̶a̶t̶c̶h̶ l̶e̶v̶e̶l̶ U̶I̶. M̶i̶s̶l̶e̶a̶d̶i̶n̶g̶ S̶e̶c̶u̶r̶i̶t̶y̶ P̶a̶t̶c̶h̶ L̶e̶v̶e̶l̶ R̶e̶p̶o̶r̶t̶i̶n̶g̶ i̶n̶ /e̶/O̶S̶ h̶a̶p̶p̶e̶n̶s̶ b̶e̶c̶a̶u̶s̶e̶ m̶o̶d̶i̶f̶i̶e̶s̶ t̶h̶e̶ U̶I̶ d̶i̶s̶p̶l̶a̶y̶i̶n̶g̶ s̶e̶c̶u̶r̶i̶t̶y̶ p̶a̶t̶c̶h̶ l̶e̶v̶e̶l̶s̶ t̶o̶ m̶a̶s̶k̶ t̶r̶u̶e̶ p̶a̶t̶c̶h̶ s̶t̶a̶t̶u̶s̶. T̶h̶i̶s̶ m̶a̶y̶ g̶i̶v̶e̶ u̶s̶e̶r̶s̶ a̶ f̶a̶l̶s̶e̶ s̶e̶n̶s̶e̶ o̶f̶ s̶e̶c̶u̶r̶i̶t̶y̶. T̶h̶e̶y̶ c̶o̶u̶l̶d̶ t̶r̶a̶n̶s̶p̶a̶r̶e̶n̶t̶l̶y̶ i̶n̶d̶i̶c̶a̶t̶e̶ w̶h̶i̶c̶h̶ p̶a̶t̶c̶h̶e̶s̶ h̶a̶v̶e̶ b̶e̶e̶n̶ a̶p̶p̶l̶i̶e̶d̶, i̶n̶s̶t̶e̶a̶d̶ o̶f̶ a̶n̶ “u̶p̶-̶t̶o̶-̶d̶a̶t̶e̶” a̶p̶p̶e̶a̶r̶a̶n̶c̶e̶ b̶y̶ r̶e̶f̶e̶r̶e̶n̶c̶i̶n̶g̶ o̶n̶l̶y̶ a̶ s̶u̶b̶s̶e̶t̶ (̶p̶a̶r̶t̶i̶a̶l̶ A̶O̶S̶P̶ p̶a̶t̶c̶h̶e̶s̶)̶, w̶h̶i̶c̶h̶ a̶p̶p̶e̶a̶r̶s̶ t̶o̶ o̶m̶i̶t̶ s̶e̶c̶u̶r̶i̶t̶y̶ f̶i̶x̶e̶s̶. 2̶. T̶h̶e̶ l̶a̶c̶k̶ o̶f̶ a̶ S̶e̶c̶u̶r̶e̶ E̶l̶e̶m̶e̶n̶t̶ f̶o̶r̶ R̶o̶b̶u̶s̶t̶ D̶i̶s̶k̶ E̶n̶c̶r̶y̶p̶t̶i̶o̶n̶, m̶a̶k̶i̶n̶g̶ f̶u̶l̶l̶-̶d̶i̶s̶k̶ e̶n̶c̶r̶y̶p̶t̶i̶o̶n̶ w̶e̶a̶k̶ f̶o̶r̶ m̶o̶s̶t̶ u̶s̶e̶r̶s̶, e̶s̶p̶e̶c̶i̶a̶l̶l̶y̶ t̶h̶o̶s̶e̶ u̶s̶i̶n̶g̶ s̶h̶o̶r̶t̶ P̶I̶N̶s̶ o̶r̶ s̶i̶m̶p̶l̶e̶ p̶a̶s̶s̶w̶o̶r̶d̶s̶ i̶s̶ d̶u̶e̶ t̶o̶ d̶e̶v̶i̶c̶e̶s̶ l̶i̶k̶e̶ P̶i̶x̶e̶l̶ p̶h̶o̶n̶e̶s̶ a̶n̶d̶ i̶P̶h̶o̶n̶e̶s̶ t̶h̶r̶o̶t̶t̶l̶e̶ b̶r̶u̶t̶e̶-̶f̶o̶r̶c̶e̶ a̶t̶t̶e̶m̶p̶t̶s̶ v̶i̶a̶ d̶e̶d̶i̶c̶a̶t̶e̶d̶ s̶e̶c̶u̶r̶e̶ e̶l̶e̶m̶e̶n̶t̶s̶, r̶e̶n̶d̶e̶r̶i̶n̶g̶ d̶a̶t̶a̶ e̶x̶t̶r̶a̶c̶t̶i̶o̶n̶ i̶m̶p̶r̶a̶c̶t̶i̶c̶a̶l̶ w̶i̶t̶h̶o̶u̶t̶ t̶h̶e̶ c̶o̶r̶r̶e̶c̶t̶ p̶a̶s̶s̶p̶h̶r̶a̶s̶e̶. T̶h̶e̶ a̶b̶s̶e̶n̶c̶e̶ o̶f̶ t̶h̶i̶s̶ h̶a̶r̶d̶w̶a̶r̶e̶ o̶n̶ F̶a̶i̶r̶p̶h̶o̶n̶e̶ 6̶ a̶n̶d̶ o̶t̶h̶e̶r̶ p̶h̶o̶n̶e̶s̶ m̶e̶a̶n̶s̶ a̶ s̶t̶a̶n̶d̶a̶r̶d̶ 6̶-̶8̶ d̶i̶g̶i̶t̶ P̶I̶N̶ c̶a̶n̶ b̶e̶ b̶r̶u̶t̶e̶-̶f̶o̶r̶c̶e̶d̶ r̶e̶l̶a̶t̶i̶v̶e̶l̶y̶ q̶u̶i̶c̶k̶l̶y̶, a̶l̶l̶o̶w̶i̶n̶g̶ e̶a̶s̶y̶ a̶c̶c̶e̶s̶s̶. T̶h̶u̶s̶, i̶t̶ i̶s̶ i̶n̶ p̶a̶r̶t̶ a̶ h̶a̶r̶d̶w̶a̶r̶e̶-̶l̶e̶v̶e̶l̶ i̶s̶s̶u̶e̶. I̶ d̶o̶ n̶o̶t̶ s̶e̶e̶ h̶o̶w̶ t̶o̶ a̶d̶d̶r̶e̶s̶s̶ t̶h̶i̶s̶ o̶n̶ /e̶/O̶S̶ s̶i̶d̶e̶. 3̶. T̶h̶e̶ P̶r̶i̶v̶i̶l̶e̶g̶e̶d̶ I̶n̶t̶e̶g̶r̶a̶t̶i̶o̶n̶ f̶o̶r̶ m̶i̶c̶r̶o̶G̶ (̶a̶ G̶o̶o̶g̶l̶e̶ S̶e̶r̶v̶i̶c̶e̶s̶ r̶e̶p̶l̶a̶c̶e̶m̶e̶n̶t̶)̶ a̶n̶d̶ G̶o̶o̶g̶l̶e̶-̶D̶e̶p̶e̶n̶d̶e̶n̶t̶ A̶p̶p̶s̶ (̶e̶.g̶., A̶n̶d̶r̶o̶i̶d̶ A̶u̶t̶o̶)̶ a̶t̶ a̶ p̶r̶i̶v̶i̶l̶e̶g̶e̶d̶ O̶S̶ l̶e̶v̶e̶l̶, i̶s̶ b̶r̶e̶a̶k̶i̶n̶g̶ i̶n̶d̶e̶e̶d̶ t̶h̶e̶ t̶y̶p̶i̶c̶a̶l̶ a̶p̶p̶ s̶a̶n̶d̶b̶o̶x̶i̶n̶g̶ a̶n̶d̶ e̶x̶p̶o̶s̶i̶n̶g̶ t̶h̶e̶ s̶y̶s̶t̶e̶m̶ t̶o̶ h̶e̶i̶g̶h̶t̶e̶n̶e̶d̶ r̶i̶s̶k̶s̶ i̶f̶ t̶h̶e̶s̶e̶ c̶o̶m̶p̶o̶n̶e̶n̶t̶s̶ a̶r̶e̶ c̶o̶m̶p̶r̶o̶m̶i̶s̶e̶d̶. S̶a̶n̶d̶b̶o̶x̶i̶n̶g̶ i̶s̶ a̶n̶ i̶m̶p̶o̶r̶t̶e̶d̶ s̶e̶c̶u̶r̶i̶t̶y̶ c̶o̶n̶c̶e̶p̶t̶ a̶p̶p̶l̶i̶e̶d̶ i̶n̶ m̶a̶n̶y̶ t̶e̶c̶h̶n̶o̶l̶o̶g̶i̶e̶s̶. T̶h̶i̶s̶ a̶r̶c̶h̶i̶t̶e̶c̶t̶u̶r̶a̶l̶ c̶h̶o̶i̶c̶e̶ c̶a̶n̶ b̶e̶ c̶o̶n̶s̶i̶d̶e̶r̶e̶d̶ a̶s̶ a̶ r̶e̶g̶r̶e̶s̶s̶i̶o̶n̶ i̶n̶ p̶r̶i̶v̶a̶c̶y̶ a̶n̶d̶ s̶e̶c̶u̶r̶i̶t̶y̶ c̶o̶m̶p̶a̶r̶e̶d̶ t̶o̶ t̶h̶e̶ h̶a̶r̶d̶e̶n̶e̶d̶ a̶l̶t̶e̶r̶n̶a̶t̶i̶v̶e̶ G̶r̶a̶p̶h̶e̶n̶e̶O̶S̶.
4. The inclusion of proprietary/Invasive services is half right half wrong. The system does not achieve genuine zero-trust privacy by default, but one should not even trust 100 % any other service or party. /e/OS includes its own cloud services (Murena services, can be considered proprietary/Invasive, but they are based on Nextcloud, ONLYOFFICE, CryptPad … thus all open source) that may not be fully open or auditably private (just the things that are public) and still rely on, in part, on other services infrastructure (). BUT: Users can opt out or self-host. Regarding the default experience, which includes for paying customers OpenAIs whisper for speech to text IME services (cloud) user can use it or use alternatives (even offline).
Some issues are fixable.
This comparison gives some further insight:
3 Likes
GrapheneOS know their stuff and always have fair technical points, but absolutely nefarious forces like … err, basically everybody else … are somehow preventing everybody from doing the right thing, which is only buying Pixel phones and only using GrapheneOS on them. It’s totally unfair and completely incomprehensible.
4 Likes
I am curious about microG getting privileged access:
DivestOS, which has been discontinued, had mostly (not fully) unprivileged integration for microG unlike /e/OS and CalyxOS where it’s privileged. /e/OS and CalyxOS also have privileged integration for Android Auto and other Google apps/services. If you install Android Auto on /e/OS or CalyxOS, it’s a highly privileged app not running in the regular app sandbox and also receives extensive privileged access via special permissions only available to OS components. microG is similar.
here I read that this is necessary:
System privileges are necessary for GmsCore to provide the geolocation API that normally ships with Gapps, “Fused Location”.
This is the geolocation API that Google has been recommending android SW developers use to obtain geolocation data for quite some years now. (Close to 10)
Android still supports the legacy geolocation API (“Location Manager”), but most apps being distributed via Google Play are probably using Fused Location, at least by default, because it is recommended by Google, though some can use both. Some FOSS apps that use geolocation (and which are typically not distributed via Google Play) only call the legacy Location Manager API.
The other issue with user-mode GmsCore for geolocation is that non system apps are often aggressively throttled by the OS for power-saving reasons. This is actually the main reason that the geolocation functionality was moved out of external UNLP modules into the GmsCore app, because modern OS’s had a habit of killing their processes and crippling location services when those processes get killed.
So this makes me curious, how does Graphene manage to have location service without issues, without giving special permissions to microG? I know there is a relatively easy way to integrate Play Services in Graphene, within the “normal” sandbox, however if it was really that normal do they do something special to get location services etc functioning without any issues?
If so why does /e/OS not mimic that? Is it just too complicated and they choose the easy route, or is it actually not that easy, or does Graphene lack in this regard?
2 Likes
Please tell me if I am wrong …
“fused location” includes “simply speaking” all Google (advertising agency) paying clients broadcasting their location constantly as in “best coffee over the road” – “HERE”.
AFAIK no, see [Fused Location] microG current only implemented 1/4 methods to getCurrentLocation/getLastLocation · Issue #2307 · microg/GmsCore · GitHub there are apparently 4 different ways to decide Location and Fused are basically all 4 of them together, see Google directly: FusedLocationProviderClient | Google Play services | Google for Developers
But maybe (indirectly) one or more methods rely on clients sending data to Google, for sure.
These people often come to trigger others or advertise themselves too much.
And they are into security rather than privacy, kinda feels like they should just mind their own business, just my opinion.
While not directly related to the article someone pointed out to me that /e/OS does not handle the Bootloader relocking correctly, basically /e/ does publish the signing keys i.e. as if one would lock a door but leaving the key inside the lock.
Other ROMs apparently handle this better(correctly).
They have not yet given me a source, but maybe someone here can confirm or deny this(preferably with a source)?
If that claim isn’t really specified, how to deny? I don’t think it refers to eelo dev / stable signing keys being public (unlikely) but the usage of the google-test-signing-key with some devices (FP3 that I know of, relating to its insufficient AVB impl.). In general I think it’s good to catalog any technical criticism.
2 Likes
Which of these are on Gitlab? I assume that’s where they would be(if they are “open source” as claimed),
it could also be possible that /e/ changed their practice in the past and the argument is now invalid(still waiting for a source from them).
However I couldnt find anything regarding verified boot or relocking the Bootloader in the /e/ Docs, which is interesting. Although it seems that in the past there was a section called “Does /e/OS allow for the bootloader to be locked on phones that support verified boot” at least it is recommended as a search term in the docs, however when selecting that there is no direct article.
Also in the Forum it says that:
While here someone apparently got a community build to lock successfully here:
to me this looks like contradictory information, so it seems that some of this is indeed out of date…
you’re not doing yourself favors currently searching the docs or rely on 2nd hand info. Use the image of your device and look at what keys the image is signed with and at the content of the vbmeta partition.
I currently do not run /e/OS, I also lack a functional spare device right now. Diving into the code on Gitlab would probably be even better, but I fear that I am not qualified enough for that.
1 Like
But wait! What are they talking about here:
> See /e/: Datenschutzfreundlich bedeutet nicht zwangsläufig sicher – Custom-ROMs Teil6 • Kuketz IT-Security Blog for several examples such as /e/OS having unique user tracking in their update client not communicated to users.
What kind of User Tracker is that?
1 Like
It’s explained in your link, where Gael is quoted:
For context, and I agree that this feature can be perceived with mixed feelings, especially because it was stupidly called „licence ID“ at the beginning of its implementation, we added it because we suffered from not having good statistics on /e/OS usage.
Of course we are not interested in tracking users at all, but we do want to know how many devices are running this or that build of /e/OS. This is very useful for making some decisions about device support and setting priorities for future development.
Just running statistics on OTA server request logs along with the device model didn’t give good results.
Now, and this is still part of our internal discussions, if we are able to find a way to get good quality stats without this OTA anon-unique identifier, we will consider it.
However, we sincerely believe that this anonID probably has no impact on user privacy (tracking IPs or device fingerprints would probably be much worse).
1 Like
A base on video to understand why some phone can get their bootloader relockable and other not :
Deep Dive Into Android: How GrapheneOS Is Locked Out
Now google changed their politics with a16 and the pixel phone, kernel and some other deep part of their os (vendor partition, etc) will not be anymore opensource…
Why /e/OS isn’t on the business with brax phone ? IodéOS did it with their new phone…
Don’t know if a porting is on the way (with /e/), but there’s a topic here about Brax3 device:
Currently the device is provided with IodéOS and is scheduled to be available near soon with Ubuntu Touch, which UBports foundation is also partner of the project.
Just to tease this out some more … Fused location is a thing in itself Fused Location Provider API | Google for Developers and I am keen to see just what sort of understatement (or irony) underlies the use of the word “Fused”.
Here is some Location info collected from my nicely working /e/OS a15 (heavily redacted in order to show my phone’s Location input sources)
adb shell dumpsys location
adb shell dumpsys location
Location Manager State:
User Info:
current users: u[0]
Location Settings:
Location Setting: true
Location Allow/Deny Packages:
Location Providers:
passive provider:
service: registered
listeners:
identity=1000/android[LocationService]
properties=ProviderProperties[powerUsage=Low, accuracy=Fine]
network provider:
identity=10103/com.google.android.gms
properties=ProviderProperties[powerUsage=Low, accuracy=Coarse]
target service=10103/com.google.android.gms/org.microg.gms.location.provider.NetworkLocationProviderService@2
fused provider:
service: ProviderRequest[@+1h0m0s0ms, WorkSource{1000 android}]
listeners:
1000/android[TwilightService]/01763C28 Request[@+1h0m0s0ms BALANCED, WorkSource{1000 android}]
identity=10103/com.google.android.gms
properties=ProviderProperties[powerUsage=Low, accuracy=Coarse]
target service=10103/com.google.android.gms/org.microg.gms.location.provider.FusedLocationProviderService@2
connected=true
gps provider:
properties=ProviderProperties[powerUsage=High, accuracy=Fine, requires=satellite, supports=[bearing,speed,altitude]]
Used-in-fix constellation types: GPS GLONASS GALILEO
Historical Aggregate Location Provider Data:
passive:
gps:
fused:
network:
What I aim to illustrate “Fused location is a thing in itself” (and may be used for instance in an app or system to the exclusion of other sources) shows in brief the final lines
Historical Aggregate Location Provider Data:
passive:
gps:
fused:
network: