Auto connect AA native mode

[quattroman09]

After launching, my Pi4 automatically connects to my phone via Bluetooth. When Livi launches, this connection is lost and doesn't reconnect until I manually connect on the phone.
However, this can also be problematic – sometimes Livi starts connecting via a dongle that isn't paired with the phone. Switching the connection method to AA on the main screen starts it.
The preferred connection is set to native. In auto mode, the phone never connects automatically.
I've tried all the modes in the AA auto-launch settings on the phone, and there's no difference.
LIVI version is 7.4.1

[f-io]

Hi @quattroman09,

the issue will be addressed in v8, which is currently in development.
This version will remove the concept of a “preferred” connection, as LIVI will support multiple sessions simultaneously.

All drivers will become independent: native Android Auto (wired and wireless), native CarPlay (wired and wireless), and the dongle. Switching between devices will take only a few milliseconds.

[quattroman09]

Hi
Will the problem with disconnecting the BT connection when starting LIVI also be solved in version 8?

[f-io]

Please test this build: https://github.com/f-io/LIVI/actions/runs/29528871458

[quattroman09]

Hi!
I've tested the new version.

1. Reconnecting the phone works. Sometimes slowly, but it works.
2. When the phone automatically connects after starting the Pi4 and Livi, Bluetooth doesn't connect. Therefore, hands-free doesn't work. After reconnecting the phone, Bluetooth works and connects correctly. So, the problem was left from 7.4.1.
3. After losing connection with my phone, the system doesn't automatically switch to the other paired device. So, I have to select LIVI on my phone each time to connect after the other device. Whether it's a native connection or a dongle doesn't matter.
4. The D-pad doesn't work in the new version of the Devices menu. The select button can only disconnect the device. Switching to another device is only possible using the touchscreen.
5. After a system restart, if multiple paired devices are available, the native connection is not made to the last active device. I had a Samsung and Xiaomi phone with the same AA settings. After a restart, the Samsung always connected first. Xiaomi had to be connected manually. I forgot to check this via dongle.
6. Changing the active AA connection didn't interrupt the connection on the other device. The "passive" device's audio player continued playing music.
7. There is no hotkey to open the Devices menu or switch between available devices.

[f-io]

-1: Needs more investigation on that side, different phones behave differently.

-2: For CarPlay we are actively dropping BT. For AA I still need to double-check, but I don't think a classic Bluetooth hands-free (HFP) link is required, since the call audio is carried over the projection session itself. But maybe this is Android and Android Auto version specific?

-3. This case needs more logging. The tricky part is deciding when a phone counts as lost: based on the Wi-Fi MAC, or the BT MAC? Some phones randomize their MAC per session, some sassions are running without BT, some are on USB, so I'm trying to derive a stable unique key from the authentication data instead, but here too phones behave differently.

-4: Thanks, added to the TODO list.

-5: First phone wins. The reconnect attempt starts with the last phone seen, but other phones may page on their own, and if they reach the BT endpoint they connect and trigger the driver to start a session. So yes, this needs a closer look at how different phones behave (power-saving mode, paging intervals).

-6: This is by design. We could send a "stop" message to the phone when a session is put on hold, but I'm not sure, there are pros and cons. For now I prefer "do nothing unless the user explicitly asks for it". For example, if you use a second phone to stream audio to the car over BT and just want to skip to another track before switching back to the phone that handles navigation, stopping the other phone would be annoying. Also should we send a "play" everytime we activate a session that was on hold? User settings per device, or as a default behavior? It is going to get complicatet, and I'm sure there are different users out there with different preferences.

-7: You can already switch between sessions with the keyboard: "Cycle Session" (default key: S). A dedicated hotkey to open the Devices menu itself doesn't exist, but there is an API for that: pnpm -C scripts/tools run telemetry:set view=devices

And of cause, there is already a newer version: https://github.com/f-io/LIVI/actions/runs/29643141561

[quattroman09]

1. I tested the connection speed only on the Samsung S25. It seems to me that the reconnection speed was reduced if LIVI had previously connected to other devices. At the time of testing, other devices were unavailable.

2. Xiaomi and Samsung behaved identically. But if i connect them via a dongle, there's no problem with hands-free.

3. I disconnected by disabling WiFi and BT. Do I need to collect DEBUG=1 ./LIVI.AppImage or any other logs?

4. Later I can try with two identical phones.

5. Maybe add a switch in the settings?

6. Thanks. I'll try.

[quattroman09]

In build 1818, I found a bug where the audio lags behind the video when first connecting after booting. About 15-20 minutes after loading LIVI, the audio temporarily stops, and after that, the audio and video become out of sync.
Reconnecting the device resolves the issue until the next system reboot.
I haven't been able to record any logs yet.
Version 7.4.1 didn't have this problem. The sound would occasionally drop out, but it was always synchronized with the image.

[f-io]

1. fixed
2. maybe / partially / please test a phone call (need to find a sim for my android / phone calls are always weird on android)
3. fixed
4. fixed
5. fixed (tested with 5 phones, all devices reconnect after app restart as well as app close -> app start)

*little side note, multi session via wired AA is not yet supported. It is kind a hard to test this with a single device. I know there are some singleton parts within the wired path that will most likely overwrite a second session. Wireless AA multi-session worked on your side?

EDIT: https://github.com/f-io/LIVI/actions/runs/29668917645

[quattroman09]

1, 3, 4 - resolved.

2. Fixed with Xiaomi Mi 11, no improvement with Samsung S25.

3. After booting the pi4, devices don't connect automatically if more than one is available at the same time. If only one device is available, the connection works correctly.
   With Samsung, I noticed that auto-connection stops working completely if LIVI had other devices in the "available" state. Auto-connection was restored after manually connecting and reconnecting again until the next session with multiple devices.
   This issue was only reproduced when connected to native AA. If one device is connected to a dongle and the other device to a native AA, connection/reconnection, etc., occurs correctly.
   I think the key here is that you test by restarting the app, while I test by restarting the Pi4 OS. Restarting the app doesn't interrupt the BT connection.

[f-io]

Can you please delete the ~/.config/LIVI folder, you can keep your config.json but please delete the rest.
You will have to connect each device manually at least one time, each device should appear in the devices.json file.

After each device is connected (at the same time), shutdown LIVI and start it again. Please do a log what happens then, and dump your devices.json to compare it.

Build version should be #1823.

I need the log, as I do not own more than one android, it is maybe just a gate that is stopping the driver from starting another session if one session is already active. You can send me the log also via mail If you do not like to share them here.

[quattroman09]

The behavior was slightly different from what was described earlier - Xiaomi connected reliably after launch, Samsung didn't.

s25_no_connect_mi11_auto_connect.log - After connecting the Xiaomi, I waited about 20 seconds, but the Samsung did not connect.
mi11_auto_connect_s25_man_con.log - After connecting Xiaomi I waited about 20 seconds and initiated the connection manually from Samsung.
auto_connect_s25_only.log - Xiaomi is unavailable. I restored the Samsung's auto-connection and recorded the log only from the S25.
devices.json - before and after deleting device.json are identical

[f-io]

Thanks for the logs, they showed (hopefully) what goes wrong.

When LIVI asks a phone to connect, it waited 25 seconds and then gave up. The problem is that the system underneath kept working on that request in the background. From then on every new attempt for that phone was refused with "already in progress", and that state never cleared. That is why your second phone stayed unreachable. Your log shows the phone itself was fine the whole time: it connected within two seconds as soon as you did it by hand.

On top of that, LIVI had two separate mechanisms trying to wake phones. One of them stopped as soon as any phone was connected, so once the first phone was up, the second one was never even tried.

The attached build changes three things. LIVI now waits long enough instead of giving up early, it recognises "already in progress" as normal rather than an error, and it cancels a stuck attempt so a fresh one can start. And only one mechanism handles waking phones now.

To test it, have both phones in range, start LIVI and do not connect anything manually. Two minutes are enough. Please start it like this so the log contains the needed detail:

DEBUG=1 ./LIVI-8.0.0-linux-arm64.AppImage 2>&1 | tee ~/livi-296.log

If you can, open a second terminal and run this at the same time. It records what the Bluetooth service itself is doing, which we cannot see otherwise:

sudo journalctl -u bluetooth -f -o short-precise | tee ~/bluez-296.log

If it works, both phones will show up on their own. If not, please attach both files and we should be able to tell why from that single run.

Build: https://github.com/f-io/LIVI/actions/runs/29767729020

---

EDIT:

One more thing before you test: your logs show a dongle connected in all three runs, in one of them it even drops and reattaches during startup. Please unplug it for this test!

A dongle has its own Bluetooth and Wi-Fi and tries to claim phones on its own, and a phone can only run one projection session at a time. With both the dongle and LIVI competing for the same two phones, we cannot tell which of them caused what. With it unplugged the run tells us whether the fix works. If it does, we can look at the two of them side by side afterwards.

To make it clear, the dongle is legacy. Multi-session only works with LIVI's native implementation for Android Auto and CarPlay. I do not recommend using the dongle for AA, it is only meant as a workaround for CarPlay if you cannot connect an MFi coprocessor to your host.

Also disable wireless CarPlay if your system does not have an MFi coprocessor. You can still use wireless CarPlay through the dongle, but the native stack will not even try to start. Leaving it enabled does no harm, it just makes the log noisier.

And yes, LIVI runs multiple sessions over a single Wi-Fi interface. There is plenty of bandwidth for it, and a session on hold barely transfers any data. I have tested up to five phones at the same time, four iPhones and one Android. Not a practical scenario, but at least it is covered.