An app named AsteroidOSSync can be downloaded on Android to synchronize data from a phone to an AsteroidOS watch. Several profiles are already supported: Notifications, Weather, Music and Battery, more could come in the future.
On the phone, AsteroidOSSync uses the SweetBlue library to access the Bluetooth Low Energy capabilities of Bluedroid as a central device. It scans for watches and implements the client part of the aforementioned profiles.
On the watch, data are usually received by a BCM20715 BT chip from Broadcom, this chip needs a proprietary firmware which is uploaded by the patchram systemd service. Once the firmware is uploaded an hci0 interface is created and can be set up with hciconfig.
The Linux Kernel can then receive BLE payloads. A newer Bluetooth subsystem (4.1) has been backported to provide newer MGMT API functionalities needed by the userspace (e.g: DBus advertisement). This MGMT API is only used by the BlueZ5’s bluetoothd daemon which exposes various DBus abstraction API. Bluetoothd also had to be patched to expose more complete advertisement payloads.
Simple and common interactions with the bluetoothd’s DBus API like checking for the powered/connected status are implemented in org.asteroid.utils.BluetoothStatus of qml-asteroid. This class is for example used in asteroid-launcher, asteroid-music and asteroid-settings.
More complex interactions with bluetoothd are implemented in asteroid-btsyncd, a user-space daemon running as a standard user (ceres) and acting as a DBus multiplexer between BlueZ and the apps. On the BlueZ side it registers BLE Services, Characteristics and Advertisement payloads. On the user side, it exposes specific API for each and every usage needed. For example, it communicates with asteroid-music with to the MPRIS API, with asteroid-launcher based on the FreeDesktop’s notification API or with asteroid-weather thanks to data saved in the dconf “register”.
In order to use BT PAN on AsteroidOS, you first need to modify the default image. Start by adding the following packages to the IMAGE_INSTALL variable of asteroid/src/meta-asteroid/classes/asteroid-image.bbclass:
bluez5-testtools bluez5-noinst-tools python-dbus connman-client
You also need to modify the bluez5’s main configuration in asteroid/src/meta-asteroid/recipes-connectivity/bluez5/bluez5/main.conf to
[General] #ControllerMode = le DiscoverableTimeout = 180
Finally, modify build/conf/bblayers.conf to add the following line to BBLAYERS:
After above changes, you can rebuild a new asteroid rootfs and install it to the watch with the usual building process.
In order to watch logs and check on progress, open up first a first terminal on the watch via SSH and run:
tail -F /var/log/messages
In a new terminal, download and push the bt-pan helper script: (more info)
wget https://raw.githubusercontent.com/mk-fg/fgtk/master/bt-pan chmod +x ./bt-pan scp bt-pan firstname.lastname@example.org:/tmp/bluetooth/bt-pan
Now, fix up DNS and make sure localhost is a known thing by modifying (if needed) resolv.conf and hosts
sh-4.3# cat /etc/resolv.conf nameserver 18.104.22.168 nameserver ::1 sh-4.3# cat /etc/hosts 127.0.0.1 localhost
Make sure you can see bluetooth in connman:
sh-4.3# connmanctl technologies ... /net/connman/technology/bluetooth Name = Bluetooth Type = bluetooth Powered = True Connected = False Tethering = False
You can now use bluetoothctl to establish a connection to your computer (more info)
sh-4.3# bluetoothctl [NEW] Controller 20:70:02:A0:1F:AC dory [default] [NEW] Device 3C:15:C2:C7:DA:95 my-rmbp2 agent on default-agent discoverable on pairable on scan on pair 3C:15:C2:C7:DA:95 trust 3C:15:C2:C7:DA:95
Launch bt-pan client which triggers bnep0 creation from connman (you will see it in /var/log/messages)
sh-4.3# /tmp/bluetooth/bt-pan --debug client 3C:15:C2:C7:DA:95 DEBUG:root:Using local device (addr: 20:70:02:A0:1F:AC): /org/bluez/hci0 DEBUG:root:Using remote device (addr: 3C:15:C2:C7:DA:95): /org/bluez/hci0/dev_3C_15_C2_C7_DA_95 DEBUG:root:Connected to network (dev_remote: /org/bluez/hci0/dev_3C_15_C2_C7_DA_95, addr: 3C:15:C2:C7:DA:95) uuid 'nap' with iface: bnep0 DEBUG:root:Finished
At this point your default route should still be rndis0 (USB OTG) instead of bnep0:
sh-4.3# ip route default via 192.168.2.1 dev rndis0 192.168.2.0/24 dev rndis0 proto kernel scope link src 192.168.2.15
If the ip/bcast/netmask fields are missing on bnep0:
sh-4.3# ifconfig bnep0 bnep0 Link encap:Ethernet HWaddr 20:70:02:A0:1F:AC inet6 addr: fe80::2270:2ff:fea0:1fac%1202001524/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:39 errors:0 dropped:0 overruns:0 frame:0 TX packets:4 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:10504 (10.2 KiB) TX bytes:148 (148.0 B)
Fix it with ifconfig and verify it worked:
sh-4.3# ifconfig bnep0 192.168.2.2 netmask 255.255.255.0 broadcast 192.168.2.255 sh-4.3# ifconfig bnep0 bnep0 Link encap:Ethernet HWaddr 20:70:02:A0:1F:AC inet addr:192.168.2.2 Bcast:192.168.2.255 Mask:255.255.255.0 inet6 addr: fe80::2270:2ff:fea0:1fac%1201331708/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:134 errors:0 dropped:0 overruns:0 frame:0 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:40369 (39.4 KiB) TX bytes:252 (252.0 B)
Now that both routes are available, data are still going over rndis0 instead of bnep0:
sh-4.3# ip route default via 192.168.2.1 dev rndis0 192.168.2.0/24 dev rndis0 proto kernel scope link src 192.168.2.15 192.168.2.0/24 dev bnep0 proto kernel scope link src 192.168.2.2
Delete default route and aad a new default one over bnep0
sh-4.3# ip route delete default sh-4.3# ip route change default via 192.168.2.1 dev bnep0
Verify default is now over bnep0:
sh-4.3# ip route default via 192.168.2.1 dev bnep0 192.168.2.0/24 dev rndis0 proto kernel scope link src 192.168.2.15 192.168.2.0/24 dev bnep0 proto kernel scope link src 192.168.2.2
You can now test your connection via ping and nslookup
sh-4.3# ping -c 1 22.214.171.124 PING 126.96.36.199 (188.8.131.52): 56 data bytes 64 bytes from 184.108.40.206: seq=0 ttl=42 time=80.094 ms sh-4.3# nslookup www.google.com Server: 220.127.116.11 Address 1: 18.104.22.168 google-public-dns-a.google.com
You will need to enable legacy mode in order to connect to legacy (BR/EDR) mode Bluetooth devices. To enable legacy mode you will need to edit the configuration file on the watch via SSH use the following command:
sh-4.4# vi /etc/bluetooth/main.conf
Now edit the contents to the following:
Next you will need to restart Bluetooth. To avoid weird behaviour its best to restart the entire system, use the following command:
[General] #ControllerMode = le DiscoverableTimeout = 180
Now you are ready to connect a Bluetooth device to AsteroidOS use bluetoothctl to connect to a Bluetooth device:
sh-4.4# bluetoothctl Agent registered [bluetooth]# agent on Agent is already registered [bluetooth]# default-agent [bluetooth]# discoverable on [bluetooth]# pairable on [bluetooth]# scan on Default agent request successful Changing pairable on succeeded Changing discoverable on succeeded [CHG] Controller 43:43:A0:12:1F:AC Discoverable: yes Discovery started [CHG] Controller 43:43:A0:12:1F:AC Discovering: yes [NEW] Device 27:EC:10:01:00:1A Gamepad. [bluetooth]# pair 27:EC:10:01:00:1A Attempting to pair with 27:EC:10:01:00:1A [CHG] Device 27:EC:10:01:00:1A Paired: yes Pairing successful [Gamepad.]# connect 27:EC:10:01:00:1A Attempting to connect to 27:EC:10:01:00:1A Connection successful [Gamepad.]#