Exactly. So why should someone waste his/her time on some ancient hardware that the developer may not even own?
I could think of 4 different approaches to this situation:
a. buy the device the dev is owning to ensure support
b. buy yourself and the dev each a better device to incentivize him/her to develop for said device
c. learn to code
d. f*** off
Hehe, I got the MiBand for free from my work. I’m not really into fitness bands anyway.
It’s just that it’s irritating that it doesn’t work.
The real problem is that there are more and more specialised Android applications that are using Bluetooth, that one has to use.
My office now has a Bluetooth locking system. Apps are available for Android and iOS.
So now I need my old iPhone to get into the office!!
And this app also needs an internet connection, so I need to put my sim in
And before you suggest it, yes I did consider changing my work…
It’s just that it’s not their fault, they are not the owners of this building, and I like the company
Yes, all the various lock-in strategies are indeed an issue and we should be trying to avoid this kind of stuff wherever possible.
I know it’s frustrating as one has not always the power to decide where and when this kind of systems are employed and at least having the option to pass-through BT from/to android apps would be great.
Still, there are so many other issues with SFOS I’m not sure which priority I would give to that.
I’m totally aware someone else may have totally different priorities, though. Having to carry around an additional phone just to access an office would clearly be a source of frustration for me too.
It’s in an area with good network coverage.
Once it didn’t open the door, but a quick restart of the application fixed the issue.
I think that this is the future for such buildings, that are used by multiple companies.
In this way there are no keys to loose, and it’s quick to give access to new employees… and also to revoke access when people leave.
Unfortunately now the owners of the building will know when I arrive in the morning (I’m usually the first, so I need to unlock the door)
… and I am forced to use an Android or iOS phone!
So that’s why I get so unhappy when the subject of Bluetooth support in SailfishOS is discussed
I would not want to call it an issue but a fact with any software project is that developers always need incentives. In a regular a day job it’s obviously the paycheck that provides said incentive to make someone get up in the morning, down unhealthy amounts of coffee and then convert the ingested caffeine into executable code.
With open source projects this is no different, there must be something that makes the developer decide to not spend the time with his friend and family, not to read a book or not go for a walk on a sunny Sunday afternoon but rather sit in his/her darkened space and create something for him/her and other people to enjoy. Without incentives there will be no software. I think most of the time with OSS developers they will create something that they want to use themselves and the fact we are benefiting from it is just a nice side effect. I think keeping that in mind will help us all better understand why some things get support and some don’t.
As I mentioned in the previous post, I perfectly understand that and it would frustrate me too if I was stuck in that situation. I don’t want to dismiss this or something just because my priorities may be different from yours, they are as valid.
I am also stuck in the “need a few key application that will not work on alien-dalvik” situation.
Internet sharing works flawlessly on Sailfish OS, so you can keep the SIM in your everday phone and use wifi-only on the backup Android device.
I’m basically using an old anroid phone as a “miniature wifi-only tablet” for the few things I can’t do on my daily driver.
(Nowadays, it’s mostly apps that need to talk low-level to devices).
In general, low-level access to hardware is not possible in android apps. So regarding USB-C, Bluetooth, NFC, etc. it all depends on what the application want to do.
In general Sailfish OS only provides to Aliendalvik a few high-level interfaces: output image to a window of the compositor, getting input from some libinput device, sending audio out.
low-level bluetooth, USB, etc. devices aren’t exposed to Aliendalvik. (That would require somebody writing a translation layer between Sailfish OS’ standard linux bluez stack and whatever is the current Android API that applications expect to see).
plugging a keyboard / or pairing a bluetooth one and typing messages in Whatsapp? works. from Android’s point of view it’s just an input device.
using the specific application to reconfigure which buttons or screen taps the physicial buttons of a game joystick map to? No that needs to be done on an Android phone, as it would require a low-level access to the device for some device-specific protocol, it’s not a simple input device.
pairing a bluetooth speaker and playing music in an app? works. It’s just an audio-out from Android’s point of view.
using the device specific application to tweak equaliser profiles, or to chain multiple speakers together? No, that requires low-level to the bluetooth stack because it’s not a standard audio protocol. You’d need to do it using the hardware buttons on the speaker (e.g. on logitech it’s bluetooth and + on the first and 2x bluetooth on the second) or do it on a separate android device.
Note that there’s currently a few audio routing problems in Sailfish OS, but there are small fixeable bugs:
Android apps don’t always succesfully communicate their intent to Sailfish and Sailfish might route the audio to the wrong device: if the camera is on in a call in Zoom or WhatsApp, Sailfish wrongly assumes this is a “ringtone” and always route the audio to the built-in external speaker, even if there’s an earphone jacked in or paired with.
USB audio routing is broken. The correct module is active, but audio is never routed to USB-C audio devices. Audio jack works fine though, it’s really specific to USB audio.
The above could probably be even manually circumvented just by directly diverting the routing in PulseAudio (either command-line or in one of the 3rd party app available on openrepos or chum) but I’ve never bothered trying as I’m not that much affected by that.
You mean using your phone as a power-bank for your earbuds?
Works, but I don’t get a menu for that, it’s entirely the charger-controller of the phone negociating with the earbuds’ one.
(Though note the above caveat about audiorouting bugs and USB-audio. My wireless earphone will charge, but no sound will come out of it, unlike when plugged in a laptop).
The only setting you get is for the behaviour when the phone is plugged in as a USB target:
Developer mode (smartphone shows as network device, you can SSH, etc.)
Media transfer (smartphone exposes pictures, etc. to computer as most standard phones and camera do).
Charging only (only charges, doesn’t show up to the USB host).
Always ask (a pop-up opens always when the device is plugged in)
No menu about charging from/to direction.
The smartphone will always be in charging only mode, until it is unlocked and/or a menu item has been picked up. (Just plugging the phone in doesn’t bring up the developer mode’s network up. You need to plug and touch the fingerprint).
No support for USB-MIDI unlick the stock Sony Xperias’ Android.
Funny side note: there was reportedly a bug in some of the earliest Raspberry Pi 4 where the wrong resistors were used on the identification pins and thus those old Pis also declared themselves as “I am an earbud” to the charger controllers.
How about we as a community start incentivising devs in that we select a few features/bugs and start a donation/go fund me where devs are awarded money to help with bug fixes maybe tht will motivate them
Is it supposed to work on android? I have quickly connected my xperia 10 iii before flashing Sailfish to an office monitor (Dell, 3440x1440) with USB-C, and there was some output on the screen. It vaguely resembled the output on the phone display. Maybe I didn’t have the right type of USB connection (Displayport vs HDMI alternate mode), but this was completely useless.
I can safely say the 10 iii supports video output just fine under Android. Any simple USBC-to-HDMI or VGA adapter works fine, 3-in-1 hubs with USB-C Power Delivery and an extra USB port works fine to also charge the phone and add externals, I.e. a mouse or keyboard. I’m simply using docks and hubs which advertise DisplayPort Alt-Mode. I find this to be a quick and effective way to test displays in my workplace. It typically takes the maximum resolution the monitor supports, the 21:9 ratio is covered dynamically by the OS to output in portrait or landscape (always letter- or pillar-boxed).
It’s important to note that Wayland leaves it entirely on the desktop environment to handle video output, unlike X. There is a wlsrandr that could work if your DE is based on wlroots, to which I don’t know if Lipstick is using that, or written to use its own abstractions. This ignores the matter that Jolla may not have implemented anything in the kernel to support DisplayPort Alt-Mode. They have at least got OTG support working, so USB flash drives are fine, and I have successfully used Ethernet adapters under Sailfish on XA2 (networking was still routing to wi-fi and 4G however, so it isn’t designed to take that still).