Having been at the other end of bug reports, I have usually preferred to have separate reports when the reported problem is inconsistent over devices/ releases/architectures. The reason being that I can easily mark three reports as fixed if I find out there is a common root-cause of failure, whereas there’s no good path forward if reports were lumped together and it turns out they did not share origins.
In the latter case, should one mark the report solved when the first problem is solved, when most of the problems are solved or when all problems are solved? Or should the report be broken up, possibly altering the meaning of history?
Having said that, I wouldn’t mind merging these bug reports if that is the preferred way for Jolla.
[Do note that the tag(s) indicating affected device(s) can only be set on the OP, not on succeeding comments. So only the original poster (or Jolla) can keep those tags up to date.]
However, I didn’t notice until after several years of use. My impression is that before the offline MLS stuff was introduced, I was able to enable Flight mode without killing GPS. So it could be that the implementation hasn’t always matched design intention.
Also, it’s a bit difficult to understand the design:
Expectation when coming from other systems is for GPS to be unaffected by Flight mode
Documentation only mentions Flight mode in the context of networking and telephony, not in the context of GPS or location
The Position toggle in the Top menu stays in the On state when enabling Flight mode
I wouldn’t think MLS has an effect here and it’s just one more source of location. Doesn’t itself work without getting cell info either. But hard to say.
Back in the days the flight mode was interpreted more strictly in turning off all radio stuff. Sure GPS is receiving only but that’s the way it turned out. It might be that other platforms did it that way back then too.
Positioning could be confusing, but it’s not the positioning itself that’s disabled, only the gps source. Though sure could be that there are no much good positioning sources in flight mode. At least directly when entering it.
I think we could just remove the flight mode tracking for GPS. Don’t think anyone’s been wanting to keep it.
Does this say that the GPS process itfelf watches if Flight Mode is activated or not and disables itself if it sees an enabled Flight Mode?
And therefore that it’s not the Flight Mode process that tells GPS to turn off?
There are no such processes, at least that clearly. Flight mode is using a state in connman and GPS has had a sort of dummy technology plugin in connman so it knows to “power it off”.
There is a second fault in action here:
Apps report that the GPS is enabled, when in fact it is disabled (by flight mode)
It is falsely reporting that the GPS has been enabled which is an actual bug, and should be fixed. (Turning off GPS in flight mode is a design choice, rather than a bug)
Maybe i am not competent enough, but for my understanding Flight Mode should disable ALL wireless devices, so they can’t interfere with device on board an aircraft. This should include GPS.
Flight Mode is a mode, where a user can use his device for example reading, looking video, playing game etc. without any wireless protocols.
I can’t imagine for what case i would need GPS when i am on the aircraft.
Again, this is only my opinion. Maybe someone use Flight Mode for something else. I use it only during flight.
In this case they use a wrong function for their needs. (In my world).
In my world Flight Mode should disable anything (TX and RX), and this is good so.
But everyone should decide for themselves.
So what shall they do in your world to switch all RF transmission off (to minimize battery loss) and they want to keep reception (Like GPS for safe arrival)?