FP1: Macadamia 1.9.9-pre3 Alpha (Android Kitkat)

[YtvwlD]

GravityBox allows you to change which buttons are in the pull-down menu and in which order.

[YtvwlD]

I tried to connect my phone to a BLE heart-rate monitor yesterday.
I could see the device in the bluetooth settings and pairing didn’t work from there (that is the correct behaviour).
But the three apps I tried didn’t manage to find the device.
I’m trying to get more information on this isssue over the next days.

Has anybody tried this yet? Did it work?

Edit: Both BLExplorer and iBeaconDetector (both on F-Droid and on Google Play) detect a device, but I’m not sure if it’s the right one. BLExplorer does connect to a device but doesn’t return any information about it.

Edit 2:

iBeaconDetector was able to find the device.
BLExplorer was able to find the device and list its capabilities (but not read the concrete values).

I took a closer look at one of the apps I tried - RunnerUp. And I noticed these lines:

    static boolean AVOID_SCAN_WITH_UUID = false;
    static boolean CONNECT_IN_OWN_THREAD_FROM_ON_LE_SCAN = false;

    static {
        if (Build.VERSION.SDK_INT <= Build.VERSION_CODES.JELLY_BEAN_MR2) {
            // 4.3
            AVOID_SCAN_WITH_UUID = true;
            CONNECT_IN_OWN_THREAD_FROM_ON_LE_SCAN = true;
        }
}

So, Android 4.3 seems to be lacking certain features.
I replaced this with the following:

static boolean AVOID_SCAN_WITH_UUID = true;
static boolean CONNECT_IN_OWN_THREAD_FROM_ON_LE_SCAN = false;

And scanning for devices does work now.
Connecting does not.

So, what I’ve learned so far:

• BLE devices have an ID and capabilities.
• Apps can search for BLE devices.
• They can add filters to scan only for BLE devices for certain capabilities.
• The BLE stack in this ROM doesn’t support those filters.

The real solution would be to make filtering work.

The quick and dirty solution would be to simply ignore any filters set by apps in android.bluetooth.BluetoothAdapter:

public boolean startLeScan(UUID[] serviceUuids, LeScanCallback callback) {
    serviceUuids = null;
    […]

This could be made into an XPosed module easily, I guess. Maybe.

I’ll try setting the next variable to true.

Edit 3: Here’s the XPosed module:

YtvwlD/XPosed-BLE-scan-ignore-filter

The code is really just this:

findAndHookMethod("android.bluetooth.BluetoothAdapter", null, "startLeScan", UUID[].class, LeScanCallback.class, new XC_MethodHook() {
    @Override
    protected void beforeHookedMethod(XC_MethodHook.MethodHookParam param) throws Throwable
    {
        param.args[0] = null;
    }
});

Edit 4: I’ve tried setting the second variable to true. It didn’t help the connection.

So, the things I’ve learned so far:

• The FP1 does have BLE support. It just doesn’t work the way it should.
• Scanning for devices works mostly (eg. BLExplorer or iBeaconDetector or RunnerUp after the mentioned modification).
• Filtering does not. Many apps know that and don’t bother setting a filter (eg. adidas train & run or Runtastic).
• Discovering the services / properties a BLE device has works (eg. BLExplorer or RunnerUp).
• Connecting to a BLE device does not.
• Scanning for a BLE device does not work from some apps (eg. adidas train & run or Runtastic - the former one calls startLeScan very often).

Edit 5: What does happen when using RunnerUp is this:

1. Enable Bluetooth.
2. Scan.
3. Found a device.
4. Stop scan.
5. Connect to the device.
6. Connected.
7. Start service discovery.
8. Disconnected. (Should be “Discovered services.”.)

BLExplorer is able to list the services.

Edit 6: I bought a relatively cheap beacon.

BLExplorer is able to find the device and list its services. It is also able to read the values of one service per connection. (So I have to close the app and reopen it to read all services.)

The app made specifically for this device (Gigaset G-tag app) was able to find and connect to the device at the third attempt but lost the connection after about one minute.

Sometimes, the app Bluetooth-Freigabe (I don’t know its English name nor its package name, yet, sorry) crashes (I don’t have a stacktrace yet). No devices are being found afterwards until the next reboot.

Edit 7: This G-tag seems to work mostly. Sometimes, there are disconnects, but it reconnects very quickly. This is good, but doesn’t help with my heart rate monitor.

And I got a stack trace from the crashes of com.android.bluetooth somewhere in my logs. I just need to find it…

Edit 8: Here’s a stack trace:

E/[Bluetooth.OPP]BtOppRfcommListener(13444): Error accept connection java.io.IOException: read failed, socket might closed or timeout, read ret: -1
E/MTKBT   (13444): [Session]the session[61458][13444] is not ready to monitor
E/MTKBT   (13444): [Session]no any more session is in list
E/Bluetooth Transport(22023): Socket Type: Secureaccept() failed
E/Bluetooth Transport(22023): java.io.IOException: read failed, socket might closed or timeout, read ret: -1
E/Bluetooth Transport(22023):   at android.bluetooth.BluetoothSocket.readAll(BluetoothSocket.java:508)
E/Bluetooth Transport(22023):   at android.bluetooth.BluetoothSocket.waitSocketSignal(BluetoothSocket.java:485)
E/Bluetooth Transport(22023):   at android.bluetooth.BluetoothSocket.accept(BluetoothSocket.java:398)
E/Bluetooth Transport(22023):   at android.bluetooth.BluetoothServerSocket.accept(BluetoothServerSocket.java:131)
E/Bluetooth Transport(22023):   at android.bluetooth.BluetoothServerSocket.accept(BluetoothServerSocket.java:117)
E/Bluetooth Transport(22023):   at ewa.run(SourceFile:432)
E/CellLocation(14358): create GsmCellLocation
E/BluetoothRemoteDevices(13444): aclStateChangeCallback: Device is NULL
E/BluetoothTethering(12657): attempted to stop reverse tether with nothing tethered
E/bt_ext_apis.c(13444): create bt.ext.adp.hfp external socket failed : Address already in use, errno=98!

And here is the crash:

E/AndroidRuntime(13444): FATAL EXCEPTION: BluetoothAdapterState:
E/AndroidRuntime(13444): Process: com.android.bluetooth, PID: 13444
E/AndroidRuntime(13444): java.lang.NullPointerException
E/AndroidRuntime(13444):        at com.android.bluetooth.btservice.RemoteDevices$DeviceProperties.access$400(RemoteDevices.java:100)
E/AndroidRuntime(13444):        at com.android.bluetooth.btservice.RemoteDevices.sendUuidIntent(RemoteDevices.java:219)
E/AndroidRuntime(13444):        at com.android.bluetooth.btservice.RemoteDevices.access$1000(RemoteDevices.java:37)
E/AndroidRuntime(13444):        at com.android.bluetooth.btservice.RemoteDevices$1.handleMessage(RemoteDevices.java:455)
E/AndroidRuntime(13444):        at android.os.Handler.dispatchMessage(Handler.java:110)
E/AndroidRuntime(13444):        at android.os.Looper.loop(Looper.java:193)
E/AndroidRuntime(13444):        at android.os.HandlerThread.run(HandlerThread.java:61)

Edit 9: The system does return devices when an app scans for them (unless there’s a filter set). But many apps don’t display any found devices.

Edit 10: I tried going back to pre2. It’s basically the same.

Edit 11: I tried going back to the unofficial 4.4.4 build. It’s the same.

Scanning takes very long and eventually finds the correct device. But it takes a few attempts. Even if the two devices are directly near the phone.
I guess many apps run into a timeout before.
Improving the scanning process would be nice. (But not that important. We didn’t have BLE in 4.2 - now we have it but it doesn’t work.)

[petefoth]

The BLE functionality is a bit unreliable - see the dedicated thread “Bluetooth connections are unstable in FP1 alpha” thread

[YtvwlD]

The system isn’t able to display the ẞ (the uppercase version of ß; U+1E9E; “latin capital letter sharp s”).

The fonts installed support it partially:

• DroidSansFallback: nope
• DroidSansMono: nope
• DroidSerif-Regular: yep
• Roboto: nope

It would be great if the fonts could be updated. (But not that important.)

[roman]

same experience here, snapchat records vids, replay them properly, but when sended out, the recevier can only see distortion (grey blocks and green marks).
same for whatsapp with shortened vids.
i am on macademian 1.9.9 pre3 alpha…

[uudddu]

Hey Fairphone Team,

I know that you are doing your best and so I would like to ask when the next beta will be published.

My problem is that with the pre3 my battery only last 12-24 hours and its a new one…

Thanks!

[Gwendal]

I would be interested in some news as well

[sampumon]

@roman

same experience here, snapchat records vids, replay them properly, but when sended out, the recevier can only see distortion (grey blocks and green marks).

This was in @chrmhoffmann’s build too, so it seems to be a regression in [hardware?] video encoder from 4.2 to 4.4.

@uudddu

My problem is that with the pre3 my battery only last 12-24 hours and its a new one…

That sounds like normal battery life for a phone in regular use

[roman]

About battery… it is only a feeling (i have no time measurement and compare) but i think in pre3, the battry lasts not as long as in 4.2… shure, it depends on how you use your phone, but normally, i was able to use my phone at least 2 days (switched off in the night), means at least 24h, maybe 30h. now i have to recharge after 1.5 days, it feels like i have around 3-6 hours less.

When i check my battery stats, it showes that the WLAN is always on. during the day, i switch it off, but the stats tell me that WLAN is on all the time. Maybe it is only a graphical mistake, but maybe wlan does not switch of properly?

R.

[uudddu]

Yes, for normal use 12-24 h would be ok. But even if I use it only a bit it is empty after this time.

It is definitively worse than with 4.2 or @chrmhoffmann’s build. (I have two relatively new batteries, and it is the same with both)

[YtvwlD]

@sampumon

This was in @chrmhoffmann’s build too, so it seems to be a regression in [hardware?] video encoder from 4.2 to 4.4.

If I remember correctly, it was in the old official releases, too. So it’s not even a regression. It’s just a bug.

[HansTux]

I have the pre3 installed, without GApps, and it lasts for two to 3 days normaly, with Conversations and Linphone running, Wireless on almost all the time.

[ben]

Wow @YtvwlD, serious detective work going on!

@YtvwlD

The real solution would be to make filtering work.

The quick and dirty solution would be to simply ignore any filters set by apps in android.bluetooth.BluetoothAdapter:

public boolean startLeScan(UUID serviceUuids, LeScanCallback callback) {
serviceUuids = null;
[…]

This could be made into an XPosed module easily, I guess. Maybe.

I work for a company developing a BLE device. Our app will only work an Android 5.0+ because the BLE stack is simply to unstable and lacking on older Android Platforms (startLeScan is marked deprecated for a reason ;-)). Still, filtering by serviceUUIDs should be possible on 4.4 and ignoring this filter can have a serious impact on battery life, because apps will use the startLeScan to determine if a known device type is nearby, which can cause connection attemps, for example.

[YtvwlD]

Well, yeah. Scanning is really flakey. It takes too long and doesn’t find a device way too often.

I don’t know what part of the issues comes from the Mediatek Bluetooth stack and what part comes from the old version of Android.

An upgrade to Lollipop could improve things. @jftr, @Douwe there is no planning regarding a newer Android than KikKat for the FP1, is it?

[Stefan]

Read a lengthy explanation why Lollipop is not possible, from someone who has tried:

Android Lollipop 5.0 for the Fairphone 1

I have been working for quite some time on Android Lollipop 5.0 (specifically, CyanogenMod 12.0) for the Fairphone 1 and, finally, I am unveiling what I have done. But do not get too excited yet; this is not a fully functional Android Lollipop 5.0 at all. Hardware accelerated 3D graphics, sensors, basic GPS or Wi-Fi do work, but audio, telephony, Bluetooth, FM radio or camera do not (for a more detailed description see below). That is a letdown, I know. Another letdown for some of you will be …

[YtvwlD]

I’ve already read this thread.
If I remember correctly, it isn’t impossible, just very unlikely and difficult.

[Stefan]

Yes, you are right. I’ve given up on that hope though…

[Gwendal]

Still no release planned? ping @jftr?

[Stefan]

@Douwe

For similar reasons, we’ve also decided to stop developing the upgrade to Android 4.4 for the Fairphone 1. This project has been an ongoing effort from our internal team as well as key members of the community, and we’re disappointed that we are not able to see it through to the end.

[emphasize by me]. .