Exception in fictive location functionality for apps where we need it

Hello together,

it seems that if the option of fictive location is activated in advanced privacy.
No application get the right one, the magic earth app too.

I don’t what’s the difference between the exact and approximation location. I would like to know.

What I represent myself and would be pretty smart is if when this function is activated
I would be possible deactivate or make some exceptions for the apps where we need to have the proper location (gps agps whatever).

For my application (or usage) for example, I have activated the fictive location as default for all apps.
Then I would like to hold it for all in general, but for the magic earth for example, I would apply the exception that it get the real location.
Currently magic earth show me my current location in spain or usa, but i’m not there.
And there are some other apps in this case that I want to give the correct location, because without this they are unusable…

Is that possible to improve it ?
Or how is it possible to use in this way if it’s already possible?

Many thanks in advanced for any answers.



it’s a natural need to have. Watch / vote on this issue to see if it’s picked up by AP development - https://gitlab.e.foundation/e/backlog/-/issues/5595


I mean if you wana use navigatiom turn off fake locagion, once u done drivibg turn it bsck on?

means that you expose the true location for all other apps which still run in background and don’t need it.
That’s exactly what I don’t want to have, means having the possibility to use some exception for dedicated apps.
What you propose it’s the “emergency solution” i’ve naturally done, but always have a weird feeling…

Exception mechanism would be really good I think, maybe with a small overview of where each apps are focusing if they have location permits. In similar way or form than the IP-address and tracker management in advanced privacy…

1 Like

What do you means with vote ?
is that possible to influence the prio of a functionality by upvoting it?
But I don’t see any mechanism like this.

Anyway I thank you very much for having put here in chat.
That’s in mean line exactly what interests me. And not just me.
Because why having a tool which only dispatch a functionality for all, and thus impact blind some other which need the true one ?

@Manoj could you please tell if the functionality
where the link given from tcecyk goes forward and will appears one day on a release?
What is currently its state?
How is it possible for users (means no programmers) to show their interest on it, and maybe give a kind of small support to the devs?

The developers need to allocate more time to evaluate the issues. There are a lot of comment in the thread - internal comments which are not visible to all users - they indicate that some more research around the code changes are required to be done. No ETA on the actual development start date is given for now.


:+1: Thank so much for taking time to answer the questions.
I don’t what does ETA means.

Do you means that this functionality will be merged one day for sure ?
I understood no idea about when, but if it comes for sure, that enough for me.

Estimated Time of Arrival


thx for this precision :+1:

Of course, it would be a dream to feed MOST apps with a fake location while others (for example navigation apps) can always have a realtime location. But I guess that is not possible, right? It’s either all or nothing?

yes currently is not possible.
And the way to know how to do it seems to be complicated
But no impossible, seems that the team need time to understand how it works.
But from design how to do applicate it in eOS they get it, a kind similar than thr tracker tool one.
Then wait & see.
I ask me how could we encourage them, without to stress them…

Seems that the developement of the feature still on on going on its way.
That fine :slight_smile: :smiley:
@Manoj ( or who else ?) I ask me on my side (user side) how could we help to support the dev team for it ?
Donation for coffee or tea ? beta tester? what else?
and and how exactly if something is needed ?


The changes required for the above-mentioned issue are quite complicated. There is a note from the developer which mentions that to achieve app specific fake location we have to modify both AOSP and microG location managers. Which means at least modify one class (com.android.server.location.LocatonManagerService) for the 3 branches (Q, R, S) of framework_base, and one (org.microg.gms.location.GoogleLocationManager) in microG. Do not see that happening on the /e/OS side only. It requires changes all around and that involves multiple teams.


Oh ok, I understand it, seems to be more complicated.

Do you know eventually if it’s feasible ? or it is still pending in analysing if it’s feasible or not?
It think it would be nice, and it make sens that it’s developed.
Seems that would spent a lot’s of time to have it. That’s not the matter I think.

I hope that it will be possible to organize & coordinate for having it in the box…