GPS

[lambdadroid]

Only opening this to make it clear that GPS is NOT working on the ROM, and to document the current status.

The situation on our tablet appears to be the following: the tablet has a combined Bluetooth/GPS chip, which communicate over the same interface. What they did on the stock ROM is hack Android's Bluetooth implementation (bluetooth.default.so) to additionally provide a communication channel for the GPS implementation (located at /data/gps/brcm_gps_unix_socket). Without this change, there is no way the (also proprietary) GPS implementation can communicate with the chip.

Normally changes like these should be made in the device specific hardware implementation (HAL), but for some reason they decided to hack it into Android's Bluetooth implementation directly. Because of that, it is pretty much impossible to port this to newer Android versions - with each major update the Bluetooth implementation is also updated with new features and other changes - the old version wouldn't work at all on newer Android versions. Bluetooth (and GPS) is entirely broken when trying to use it on Nougat.

This does not only affect our tablet, but also some other smartphones from ASUS, e.g. the Zenfone 5.

With that said, it's unlikely that GPS will ever be working on this ROM, at least not unless ASUS releases the necessary source code for this setup. And this is likely never going to happen.

[Mis012]

It seems at least the translation from hci to /data/gps/brcm_gps_unix_socket is trivial:
sample program using the socket: https://github.com/opensourcechipspark/platform_external_bluetooth_bplus_bluedroid/blob/rk30/mid/4.4_r1/release/test/bluedroidtest/gpst.c

char buf[100] = {0xFF, 0x00, 0xFD, 0x40, 0x00, 0x00, 0xE6, 0xFC}; is sent to the socket
0x01 0x89 0xFC 0x09 0x08 0xFF, 0x00, 0xFD, 0x40, 0x00, 0x00, 0xE6, 0xFC vendor specific command is sent via hci
reception is confirmed: 0x04 0x0E 0x04 0x01 0x89 0xFC 0x00
data(MEIF?) is sent back: 0x04 0xFF 0x0D 0x10 0xFE 0x00 0xFD 0x40 0x00 0x00 0xF1 0xB1 0x14 0x20 0xED 0xFC
data appears on socket:

0xfffffffe 
0x 0 
0xfffffffd 
0x40 
0x 0 
0x 0 
0xfffffff1 
0xffffffb1 
0x14 
0x20 
0xffffffed 
0xfffffffc

apart from ffffff mysteriously appearing in some places, these are the bytes sent over hci.

So:

1. program sends bytes to socket
2. one byte of unclear meaning is prepended (checksum?)
3. the bytes are sent as payload with vendor-specific command 0xFC89
4. the chip confirms command was received
5. vendor specific (0xFF) hci event is received
6. the payload, apart from first byte (checksum?) will be received by the program
7. except some bytes have ffffff prepended

[Mis012]

Actually, in the response, checksum is unlikely, since it's always 0x10. Maybe some id?

[Mis012]

turning location off seems to have no effect at this level. how reassuring...