Device still discoverable even if bluetooth interface is closed

Bug Reports
#1

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

PRECONDITIONS:

See this tjc thread bluetooth battery drain if media-player still open - together.jolla.com

STEPS TO REPRODUCE:

  1. activate Bluetooth
  2. Power Headset on
  3. Pair smartphone with headset
  4. Start media-player & play music for more than 15min
  5. Stop/pause player through headset or Cover or lockscreen (player still opened)
  6. Put the headset in etui (they go then automatically off)
  7. deactivate Bluetooth of smartphone.
  8. Then comes this huge power drain.

EXPECTED RESULT:

Reduced autonomy from 5d to 1d
Device still discoverable on bluetooth

ACTUAL RESULT:

ADDITIONAL INFORMATION:

(Please ALWAYS attach relevant data such as logs, screenshots, etc…)

5 Likes
Community meeting on IRC 2nd February 2023
[4.3.0.12] [Xperia X 10 II] Fragile bluetooth stack
Community meeting on IRC 21st July 2022
#2

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.

1 Like
#3

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.

1 Like
#5

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

Don’t know what is the dsme …

#6

Maybe this
http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Architecture/System_Software#Device_State_Management_Entity_.28DSME.29
brings you on track?

#7

My steps were:

  1. Activate Bluetooth
  2. Set visibility to Always
  3. Deactivate Bluetooth
  4. Device is visible as type Other

I’ll test your steps later and also test if restart makes any difference

#8

thank you @peterleinchen any idea on how to get the info why the dmse sent the reboot command?

#9

Nope, sorry.
On N9x0 it was the mainly watchdog but on SFOS…

#10

On my Xperia 10 + SFOS 3.3.0.16, I could also reproduce this problem.

Regarding to Bluetooth there are two settings:

  1. Bluetooth on/off, and
  2. 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.

1 Like
#11

Thank you for the post and all the comments. We have created a bug report for this.

2 Likes
Community meeting on IRC 21st July 2022
#12

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

#13

Hello, the report status is still open. I will update when the situation changes.

3 Likes
#15

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.

1 Like
#16

Change your car stereo bt pairing code to 0000, then try again. Not ideal but should work

1 Like
#17

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.

#18

We still seem to have an open bug report about this internally. I’ve tagged it here as “tracked” just to make that clear.