Gadgetbridge: support for android wear devices

[tristan-k]

There is an open source iOS implementation for android wear called Aerlink and there is also microG GmsCore which is tinkering with the Wearable API.

Wearable API: Some initial work done, nothing usable, applications may crash.

Is support for android wear devices on the roadmap for gadgetbridge?

Right now there is no way to connect to wear devices without installing proprietary google play services.

https://github.com/microg/android_packages_apps_GmsCore/issues/4
https://www.reddit.com/r/AndroidWear/comments/3gblam/android_wear_without_google_play_services_xpost/
https://www.reddit.com/r/AndroidWear/comments/3pht3i/aosp_android_wear/
http://stackoverflow.com/questions/30063783/android-wear-without-google-play-services
http://android.stackexchange.com/questions/92652/what-can-one-do-with-the-android-wear-aosp-is-it-possible-to-build-flash-a-rom
http://forum.xda-developers.com/android-wear/help/alternative-to-android-wear-using-wear-t3117932
http://www.theregister.co.uk/2015/05/29/google_android_wear_latest/

https://github.com/microg/android_packages_apps_GmsCore
https://github.com/GuiyeC/Aerlink-for-Android

[cpfeiffer]

You mean, we should create a generic Android Wear app that can receive notifications from Gadgetbridge? Good idea! I haven't looked at Wear yet, but it sounds fun.

I haven't looked at your links yet, so I don't know of it's possible at all to receive anything on Wear without GPS, given the resource constraints on such devices.

What do you have with the iOS implementation in mind? Might that allow sending notifications to Apple Watch, iPods, etc?

[tristan-k]

I'm not sure if it is as easy as that, because of the dependencies to the Google Play Services, but basically I thought of Gadgetbridgeas as a Drop-in replacement for the google wearable app. The iOS implementation is just a proof of concept that it's possible to communicate with wear devices without google proprietary stuff.

[jonathanamorford]

The entire API between Android Wear devices and Android is provided by Google Play Services. Therefore, my guess is that microg will need to implement the Wear communication API before Gadgetbridge would be able to even access a Wear device (unless a nonstandard API were implemented as with the aforementioned app). It would make sense for microg to implement the API and for Gadgetbridge to act as the Android Wear app with the UI since it already is built to act in that capacity.

[jonathanamorford]

It appears that more work on the wearable API has been done in microg, and a new repository for it was created here: https://github.com/microg/android_external_Wearable

[mar-v-in]

microG GmsCore will require a companion App like Android Wear App is for Google Play Services and it seems like Gadgetbridge would be a nice choice for that. Until now however, the reversing and re-implementation of Play Services is not yet in a state that would allow for that to happen. I will report back here once that is the case and will try to help where possible in making this happen :+1:

[cpfeiffer]

Cool, thanks for the heads-up, looking forward to that! That actually makes me want an Android Wear device :-)

[alexmaloteaux]

In the long term, is it not better to create a new communication stack inside an aosp based wear rom like this one http://forum.xda-developers.com/gear-2/development/please-help-kernel-compiling-android-t2992953 and fully wipe the google stack;
This could lead to a an open standard of commnications between aosp wear and aosp phone; actually proprietary Android wear are just extensions of gapps or other proprietary framework (huawai, samsung, ..)

[jonathanamorford]

@alexmaloteaux microG implements the Google proprietary API with open source code. In theory, down the road, you could have the Gadgetbridge/microG stack talk to the Google stack with no problems (No custom ROM on the watch needed at all). In addition, apps built for proprietary Android Wear will run on the Gadgetbridge/microG stack. There is however a ton of code that hasn't been written at present to realize this yet.

[alexmaloteaux]

@ibleedbinari it implement the google api while removing the communication between microg / google servers and preserving privacy or it is juste the same but opensource ?

[jonathanamorford]

@alexmaloteaux Precisely how you said it. It implements the functional APIs while removing the tracking/analytics so it preserves privacy. The only communication with Google servers is for logging in and Google Cloud Messaging/push messages.

[mar-v-in]

Maybe a few words on the protocol used be the phone to communicate with the watch at this point. The basic concepts are rather easy and publicly specified on Google's documentation:

• Devices are connected in a wear network. By design, wear networks can contain arbitrary number of phones and wearables, however Google decided to restrict them to a single phone node right now. Devices in a wear network communicate and sync using p2p connections.
• There are 3 types of communication types: Channels, DataItems and Messages.
  
  
  
  • Channels require an active connection to the phone device and are basically a bi-directional bytestream connection (including data acknowledging etc).
  
  
  • DataItems are synchronized on the whole wear network. New or modified data items are pushed to connected devices directly or send later when they reconnect. There is no specific system to acknowledge DataItems. Play Services ensures that DataItems can only be read by the application that created it.
  
  
  • Messages are directed to a single device and are acknowledged by the device that was able to send it to the target device.
  
  

A few important things I'd like to add here, that are not documented by Google:

• The protocol itself does not contain messages, so I assume they're actually send using a DataItem and an acknowledging DataItem.
• This basic structure is implemented in Play Services and is used by all apps using Android Wear. It will thus be re-implemented (including the APIs) in microG GmsCore.
• The Android Wear app is just an application that communicates over this system. It forwards system notifications, incoming calls, etc as DataItem through the API provided by Play Services to the wearables. The Android Wear app running on the wearable will then create a device specific notification from that information and do whatever it wants to. Gadgetbridge should basically act as this "Android Wear" app on the phone - as it already does all the notification related stuff for other wearables it's predestinated for that task. Longterm there should be a free implementation of the wearable part of the "Android Wear" app, but I consider it a minor as we do not request this for all the other smartwatches yet.
• The protocol for device to device communication is based on protocol buffers. You can find the current state of my reverse engineered proto spec here. This protocol is transferred in three ways: Over a bluetooth link, via tcp connection (to connect to the Android wear emulator) or using the Google cloud, so that the target device can also receive the data via wi-fi. The cloud based synchronization works for DataItems only and data packets are end-to-end encrypted. The key exchange is done via a different channel (bluetooth or tcp).

The fact that cloud communication is end-to-end encrypted makes it interesting even for people that do care about privacy. Longterm we would want a way to use our own servers for that. However this is all in the microG part and not that relevant for Gadgetbridge.

I will report back here once I got some other nice info for interested people :) Feel free to ask anything Android Wear protocol related

[jonathanamorford]

@mar-v-in Could Gadgetbridge start work by implementing the API as per Google's documentation since microG will be following spec? That way we'd have a fully functioning system sooner.

(Also really cool information. Thanks for sharing!)

[cpfeiffer]

Yes, indeed, thanks for sharing your insights!
@mar-v-in So basically, right now, we could implement a free replacement of the "Android Wear" app inside Gadgetbridge, which would use the Google Play Services API (for now) to

• receive cloud notifications
• create device specific notifications from cloud and local notifications in order to forward them to the wear device/emulator

Is the device to device communication (via bluetooth, tcp, cloud) part of Play Services/microG or would that be done inside Gadgetbridge?

[mar-v-in]

Google cloud synchronization and device communication are both implemented in Play Services and thus I think it's best to have them in microG as well.

The Android Wear app communicates with Play Services for two things:

• Notifications: incoming call, status notifications, google now, ...
• Device management: connecting new devices, configuring the watchface, ...

For notifications Android Wear uses DataItems (I don't know details, but that's something easy to find out) and sends them to device using play services API (which will automatically decide if it should use cloud or direct communication channel).
Device Management is done using a hidden API in play services. You can find some details on this API here (the normal data items are there as well). All of this is still in development, but these hidden APIs are normally restricted to be only used by the Android Wear app. I think we will define a permission that can be requested by Gadgetbridge so they will be able to use those APIs.

I can understand that you are eagerly awaiting this feature (I am as well :smile:), but currently there is not much useful you can do in Gadgetbridge. I will come back here once I got data items over tcp connection working, so you can start developing the notification part and test it against the Android Wear emulator. If you want to help with that part (which will then go in microG) as well, I will happily share other details with you - maybe you want to join #microg on freenode for that...

[cpfeiffer]

Alright, so the part of Gadgetbridge is probably rather easy compared to that of microG :-)

Now that I have a picture in my mind, I could start adding the generic boilerplate code for Wear devices in Gadgetbridge. Don't worry, I'm relaxed, I don't even have a wear device, yet. But I can imagine the grumpy crowd when microG is "ready", but Gadgetbridge is not ;-)

[tristan-k]

I just wanted to throw something in the discussion: there is a new alternative firmware for android wear devices called AsteroidOS. Github is here. It's compatible through the library "libhybris".

[ashimokawa]

@tristan-k
That is interesting, as soon as there are supported watches with one week of battery. Maybe never. ;(

[jonathanamorford]

@cpfeiffer I'll start to look into how Gadgetbridge works so I can help code when microG is ready
@mar-v-in If I can help with the microG wear implementation, send me a message
@tristan-k Very interesting! From the looks though, that would require a totally separate implementation, and since it is already open source, may not need to be added to Gadgetbridge. I'll be keeping an eye on that project.

[cpfeiffer]

@ibleedbinari great! We should document Gadgetbridge's architecture somwhere on the wiki. If you have any questions, please do ask. For a start, I added some preliminary documentation here: https://github.com/Freeyourgadget/Gadgetbridge/wiki/Developer-Documentation

[tristan-k]

Any news on this? AsteroidOS lately published a companion app in f-droid. Is it possible to us Android Wear with microG?

[mar-v-in]

The bluetooth part is still completely missing, but it is possible to use it via TCP, which is what is done to connect it to the android wear emulator. There is still a lot that can go wrong and the software on the watch is really crap (wrong data from device can lead to crash) so you probably don't want to use it on a real watch anyway. The bluetooth part shouldn't be too complicated.

I will set up a guide on how to connect it with the emulator and details on what has to be done by Gadgetbridge when I find some spare time (christmas holidays I guess).

[cpfeiffer]

Cool, looking forward to that :-)

[tristan-k]

@mar-v-in In the meantime is it possible to use com.google.android.wearable.app with microG?

[tristan-k]

To answer my own question. It seems it is not possible to use the official android wear app together with microG. Android Wear keeps asking for a update of com.google.android.googlequicksearchbox (which also have to be installed) even though it is the latest version.

[Technohacker]

any progress guys?

[cpfeiffer]

@Technohacker My understanding is that microg is not ready yet, that's why Gadgetbridge did not attempt to become a Wear broker yet.

[Technohacker]

@cpfeiffer yeah I agree, i've tried syncing my device with the official app but no luck. It stopped at a point where it was trying to start a Bluetooth OBEX FTP connection to the watch, AFAIK