Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GPS #3

Open
lambdadroid opened this issue Mar 3, 2018 · 3 comments

Comments

2 participants
@lambdadroid
Copy link
Member

commented Mar 3, 2018

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.

@lambdadroid lambdadroid changed the title GPS support GPS Mar 3, 2018

@Mis012

This comment has been minimized.

Copy link

commented Jan 6, 2019

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

This comment has been minimized.

Copy link

commented Jan 6, 2019

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

@Mis012

This comment has been minimized.

Copy link

commented Jan 6, 2019

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

@lambdadroid lambdadroid transferred this issue from me176c-dev/android_device_asus_K013 Feb 17, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.