Fantastic work @rdav. I shall slaughter a fatted calf in your honour.
I’ll reiterate, This works for me.
SF & Android at the same time is merely a nice-to-have.
It’s no excuse not to implement it.
Looking forward to an app or patch to toggle this.
A top-menu switch would work for me.
I don’t care if it has to kill all running apps.
Android+BT is more occasional use rather than always for me. I have plenty of non-BT-using Android apps that I run, while wanting SF to have the BT as normal.
The audio is handled by appsupportaudio systemd service. I haven’t tried but systemctl stop --user appsupportaudio might work. There might also be another line to change in that config file, try searching for that service or simply “audio”.
Could we create the script and then call it via situations app…then we could make it even triggered by external events…like leaving home wifi -» switch bt to AAS and similar things.
I really wonder how you guys come up with this calls always. Its awesome.
I also want all apps in sfos so i dont need AAS at all but because I want to stay in contact with different people I have to use whatsapp…yet I still miss Mitakuuluu / WhatsUp dearly ( who remembers?). Browsing? I basically gave up with native browsers…sometimes the sailfish browser is ok but Fennec with adblocker is my default …no discussion…Banking apps???
And now the killer reason…Tesla… I drive right now a rented/leased Model 3 to see how electric works for us and Teslas dont come with keys!!! You either use a blank plastic card that you have to touch the B pillar with or use the app which needs mobile data AND BT always!
One of the reason why I will never buy it… Imagine your phone gets empty while you are not close to the car. hiking for example… Yeah fun times.
I now need always my work iphone with me or that card which is like using a car key in the lock… Nothing works remote…
So yeah… Too much stuff is already locked in with ios and andro…
Ha! I knew this would come.
No thats not an option as the car is not mine and never will be Im just a long period rent customer ( car was used already before me).
And to be honest in a car for that price I would DEMAND this “key” to be included by default.
Sadly, the Tesla app for Sailfish does not yet unlock the car automatically. While it does support Bluetooth LE, it still needs to actively send a command to the car to lock/unlock it.
One option would be to buy a Model 3 keyfob from eBay, use it for as long as you drive the car, then sell it again, likely for the same amount you paid.
(Or you might decide to buy a Tesla and keep the key fob )
I see it a bit differently. Ninety-nine per cent of people don’t need it. Most carry their phones anyway, and they can always keep a keycard in their wallet as a backup in case the phone fails. Why waste a relatively expensive item like a keyfob for so little gain?
As stated above, if the phone fails, it’s easy to just use the keycard as a backup. Unlike a key, it’s thin and convenient, at least for anyone who already carries other cards anyway but no physical keys.
Unlike legacy automobiles, a Model 3 can have 19 cards/fobs/phones registered at the same time, and adding or removing one takes only a few seconds.
Outdoors GPS is pretty good, but indoors AGPS has been one of those SFOS evergreen disasters from the start. Even suplpatch doesn’t really help, since it doesn’t operate over wifi. I could really use AGPS ability as well.
I currently have only two use cases that require Bluetooth support in AAS. If I can adapt this ‘solution’ to allow toggling of BT support (to AAS, then back to SfOS) there will be nothing preventing me from using my Xperia 10 iii as my ‘daily driver’ device. All the other use cases for Bluetooth in my current Android phone can be achieved in SfOS without needing Bluetooth support in AAS.
My use cases:
Garmin Smartwatch: download golf course data from Garmin Connect Android app running on the phone. As far as I know, this is the only way to achieve this: it is not possible to download Golf Course data from PC to watch. (Note this is a multi-sport watch and golf courses are not pre-loaded: they must be loaded from the phone. For dedicated Golf watches, with courses preloaded, course updates can be downloaded from PC or Web)
BeMore Hearing Aid control app. Proprietary Android app that allows fine-grained control of hearing aids - volume, noise filters, favourite settings
These operations are both short in duration: the workflow would be
Enable BT in AAS
Perform the operation
Disable BT in AAS and re-enable it in SfOS
I think this is achievable by creating scripts:
Enable BT in AAS (bt-to-aas.sh)
stop AAS if it is running - (is this doable from a script?). Or leave it running while we do steps 2 & 3, and restart ASS in step 4
stop bluetooth and bluebinder services
add (or uncomment) this line (using sed?) to /opt/appsupport/etc/appsupport.conf.d/10-hybris.conf Proxies=android.hardware.bluetooth@1.1::IBluetoothHci,android.hardware.bluetooth@1.0::IBluetoothHci/default
start (or restart) AAS - (is this doable from a script, rather than from SFOS settings menu)
Enable BT in SfOS (bt-to-sfos.sh)
I am less sure about what is needed here. A 'quick and dirty solution might be to edit the 10-hybris.conf file then reboot the phone. I would prefer a slightly more elegant and less destructive solution
do I need to stop bluetooth and bluebinder services again, or are they still not still not running since being stopped in the bt-to-aas.sh script?
stop AAS
is this necessary or can we just restart it once we have changed the 10-hybris.conf file?
is this: do-able from a script ?
OR disable AAS Android Bluetooth package, but leave AAS running
remove (or comment) this line( using sed?) to /opt/appsupport/etc/appsupport.conf.d/10-hybris.conf Proxies=android.hardware.bluetooth@1.1::IBluetoothHci,android.hardware.bluetooth@1.0::IBluetoothHci/default
restart bluetooth bluebinder and services
restart AAS (optional: we could leave this to be done manually)
Running the scripts from an on-screen button or widget would be ‘nice to have’, once I am happy with the script functionality.
Some of the operations would require devel-su. Are there ways of working around that so that the scripts can be invoked by ‘normal’ users? e.g.
invoke the scripts using devel-su, and reading the devel-su password from some (hidden and maybe encrypted) file?
change the permissions on the scripts to make them executable by all?
some other magic?
Note I am very new to SfOS, and don’t have a great deal of experience with shell programming, either so I apologise for any basic errors and misunderstandings.
Any thoughts or suggestions on the above before I start experimenting?
Thanks
EDITs:
Re-reading the thread, I saw the following posts
I could look into that, but I don’t think it works well for my use cases. I will likely be running AAS most of the time, alongside SfOS, so I want to enable BT in AAS only when I want to perform one of the operations, leaving BT enabled in SfOS the rest of the time
I have less experience of systemd than I have of shell programming. Which is likely to be easier - systemd unit or shell script?
You can run scripts as root by using qCommand app or Sailcron (at selected time). Scripts which don’t need root are possible to run from launcher by creating *.desktop file.