REPRODUCIBILITY (% or how often): no idea, i remark it for the 1st time. Repro is not that easy
BUILD ID: v3.3.0.16
HARDWARE (Jolla1, Tablet, XA2,…): sony xperia xa2+
UI LANGUAGE: french
REGRESSION: (compared to previous public release: Yes, No, ?):
DESCRIPTION:
Related to the following tjc-thread. After using my device with ny divacore true wireless headset came to the issue of a huge battery drain, which give an only one day autonomy to my device instead of 5.
Today I got a further info about this issue. I get a huge frighten as I remarked that in this state with the battery drain after use my true wireless headsets with Bluetooth.
After use these I closed the Bluetooth interface, and thought it was closed. The gui display it as closed too. But my device is still on Bluetooth discoverable even if the Bluetooth is closed. All other device see it!!! I saw the bluebinder process on working through the “top” cli command.
Has someone has experimented some similar experience?
Could someone help, i’ll give any further information
I can confirm this bug on my Sony Xperia XA2 (Dual SIM) running SFOS 3.3.0.16.
I would also claim that the reproducibility is about 99%.
My device visibility inside the Bluetooth settings is set to always, it needs to be tested if the device will be visible all the time (with deactivated Bluetooth) using the other settings too.
With my XA2 reproducibility is 100% with visibility setting Always. Got same result once with 3 min timet but after that couldn’t reproduce.
Jolla Phone didn’t behave like this art all. Interesting detail was that when bluetooth was off with always, XA2 was shown as device type Other. Bluetooth on it vas shown as phone.
Fine! wanted to let my device in last stand for having more material to analyse.
It has rebooted itself on midday.
Now the device is not any more visible.
by applying cmd “last reboot | head -1” saw when it has restarted.
It restarted at a time that when i was far away.
the systemboot.log told that shutdown request from dsme
20200707_074910 Received: dsme internal state USER
20200720_123055 Received: shutdown request from dsme
20200720_123056 Received: dsme internal state SHUTDOWN
20200720_123100 Shutdown: SW shutdown request
20200720_123140 Startup: Reason Unknown
20200720_123140 Received: dsme internal state USER
On my Xperia 10 + SFOS 3.3.0.16, I could also reproduce this problem.
Regarding to Bluetooth there are two settings:
Bluetooth on/off, and
in Settings/Bluetooth, visibility on/off.
My results are:
BT on & Visibility on: visible, coupling from other device possible
BT on & Visibility off: not visible,
BT off & Visibility was off before switching BT off: not visible,
BT off & Visibility was on before switching BT off: visible!! coupling from other device not possible
So for me the workaround is to switch off visibility manually before switching BT off. So my device stays invisible, but I agree, this is not really satisfying… But it is possible to make the device invisible and save battery power and increase data safety.
Problem still on 3.4. @jiit could you provide more info about the ticket?
Has someone already gave a look?
Or it is already planed for a specific future version?
Have nice time.
Cheers
I’ve just had an opportunity to enjoy this ever-green bug on a 4.4.0.64 XA2 Ultra Dual. Turning off Bluetooth, and even enabling Flight Mode, has no effect on device discoverability. Other devices (including e.g. my wife’s iPhone 7) still discover it. Even devices which are not paired with it and had no previous connections with still it discover it and show its correct name.
Another story (enough for a bug report) is an hour wasted on failed attempts to pair it with a Bluetooth car kit (Citroen/Peugeot KML). It doesn’t allow entering the code (1234) so the car kit rejects pairing.
Not possible, unfortunately. Those Siemens/Continental made KML (Kit Main Libre) units don’t allow changing the code. 1234 is hardcoded.
An interesting thing is that a few months ago I was able to pair that very same phone (but a few OS updates earlier, 4.3.0.12 if I remember correctly) with the same model of car kit (not the same unit, but identical model). So it looks that something got worse in 4.4.0.x.