Database Info

Camera - Manual Focus

Hello devs!
I wonder if anyone is interested in/capable of implementing a manual focus feature in android, at least for G1. Hardware-wise, I think it is probably feasible since (the great dev) DZO has already done it for the Kaiser (and I have seen it in action)!
CLARIFICATION EDIT: by Manual Focus I mean controlling the focal length, not just triggering the autofocus. For example, on the Kaiser, dzo has mapped the up/down side-wheel to focus-farther/focus-nearer!
See here the source code commit.
It would be great if the implementation introduced a relevant Java-level API, or extent the current Camera API.
My idea is to use this feature to fix-focus the camera, just a few centimeters away and make barcode scanning faster, not relying so much on auto-focusing. But I'm sure that there are plenty more useful stuff that can be done with manual focus (e.g. inspiring/artistic photo captures).
I'm rather new in android-dev and not experienced enough (yet) to work on the below-Java space, that's why I'm kindly asking for someone else to have a look at it
any thoughts?
have fun,
hypest

This is a great idea. Hope to see someone working on it.

This would be awesome! Espcially for photographers like muah

lapalways05 said:
This would be awesome! Espcially for photographers like muah
Click to expand...
Click to collapse
Photographers use shoddy-quality 3MPx cameras? Is your dSLR in the shop or something?

MattKilla said:
Photographers use shoddy-quality 3MPx cameras? Is your dSLR in the shop or something?
Click to expand...
Click to collapse
No, but it's not in my pocket most or all of the time, either. In a pinch, between 3Mpixel and 0Mpixel, the photographer will usually choose the former.

marxmarv said:
No, but it's not in my pocket most or all of the time, either. In a pinch, between 3Mpixel and 0Mpixel, the photographer will usually choose the former.
Click to expand...
Click to collapse
Yeah exactly. I love my dSLR to death, but I can't always have that beast with me. My phone is ALWAYS with me. I would a lot rather take a quick shot with it than no shot at all.
To the OP. Look in the android source repo at the camera code. Or is the G1 camera drivers in the closed source area? I know the actual camera driver is (thats why 2.X didnt have a camera at first) but is the AF code there too?

As the phone has auto focus i see no reason why manual focus couldn't be coded in.
In fact, i'm surprised no one has done it yet. I remember it being done on my old LG Viewty (that had a fantastic camera) and my SE k750i and was great for the really close up shots that the auto focus can't normally achieve.

Ok I looked at the code. Here is the camera code for the MSM7xxx chips:
http://android.git.kernel.org/?p=pl...=libcamera/QualcommCameraHardware.cpp;hb=HEAD
http://android.git.kernel.org/?p=pl...;f=libcamera/QualcommCameraHardware.h;hb=HEAD
http://android.git.kernel.org/?p=pl...a=blob_plain;f=libcamera/camera_ifc.h;hb=HEAD
If you look at the first one, it does all its autofocus calls thru libqcamera. That is one of the proprietary HTC/Qualcomm drivers. Here is the code:
Code:
status_t QualcommCameraHardware::autoFocus(autofocus_callback af_cb,
void *user)
{
LOGV("Starting auto focus.");
Mutex::Autolock l(&mLock);
Mutex::Autolock lock(&mStateLock);
if (mCameraState != QCS_PREVIEW_IN_PROGRESS) {
LOGE("Invalid camera state %s: expecting QCS_PREVIEW_IN_PROGRESS,"
" cannot start autofocus!",
getCameraStateStr(mCameraState));
return INVALID_OPERATION;
}
if (mAutoFocusCallback != NULL) {
LOGV("Auto focus is already in progress");
return mAutoFocusCallback == af_cb ? NO_ERROR : INVALID_OPERATION;
}
mAutoFocusCallback = af_cb;
mAutoFocusCallbackCookie = user;
LINK_camera_start_focus(CAMERA_AUTO_FOCUS, camera_cb, this);
return NO_ERROR;
}
First off you can see its calling the QualcommCameraHardware library which is libqcamera and then the method autoFocus. I think this is a dead end.
However, for 2.X we reverse engineered the drivers since we didn't have them available. They are open source. We may be able to look at them and get how they use the AF code.

Geniusdog254, thanx for sharing your thoughts, info and findings.
I'm assuming here: if the AF is done in software, even in proprietry drivers, it may indeed be possible to use it by RE it. Best case scenario would be to find functions lingering in there, waiting to be called
I'm wondering though, if the IOCTL's dzo is using are directly triggering hardware "switches", or are they handled in the drivers...
Could you please also share links to the open sourced 2.x driver?

Geniusdog254 said:
First off you can see its calling the QualcommCameraHardware library which is libqcamera and then the method autoFocus. I think this is a dead end.
Click to expand...
Click to collapse
Maybe not. I vaguely remember that the HTC camera app from CM 4.0 or 4.1 would allow you to switch between autofocus and infinity focus. Maybe that's a start?

I found these symbols in the libqcamera.so on my CM g1 (and highlighted some interesting ones):
Code:
af_algo_config
af_algo_execution
af_algo_preview
af_check_aec_settled_cnt
[SIZE="5"][B]af_do_move_lens[/B][/SIZE]
af_done
af_do_process_exhaustive_search
af_do_process_hill_climbing
[SIZE="5"][B]af_do_reset_lens[/B][/SIZE]
af_do_safe_move
af_init_process_exhaustive_search
af_init_process_hill_climbing
af_is_active
[SIZE="5"][B]af_move_lens_to[/B][/SIZE]
af_process_focus_sensor
af_process_lens_move_done
af_process_start_focus
af_process_stats
af_read_process_type
af_read_sharpness
af_start_stats
af_stop_focus
seems to me that maybe there are suitable means for manipulating the lens/focus.
I've attached the whole readelf dump...

I'd love to see this implimented

I think that if with proprietary drivers we can't manually move the hardware, perhaps we can indirectly trick it into focusing closer, thinking that it's "autofocusing" on a close object. Either one of these methods is a bit of a longshot with a proprietary driver, but they are both worth exploring. I'd LOVE to see some control over the focus of the camera, and if we can't do it with the AOSP code, let's look at Hero.... it offers significantly more focus control, with touch-to-focus. I haven't even glanced at the code there, though, so I have no idea. I'm just throwing thoughts at the wall in hopes that one of them will stick.

Here is the code for the opensource, reverse engineered driver for eclair. Have it at, I may look & post my findings:
http://gitorious.org/eclair-camera-drivers
EDIT: Well of course I'm looking at it lol, I can't resist.
Look on line 345 of this page (they're numbered): http://gitorious.org/eclair-camera-...are_msm7k/blobs/master/libcamera/camera_ifc.h
CAMERA_PARM_FOCUS_STEP is defined. It sounds like a way to step the focus forward/backward but I don't know which way.
Also, there is a LOT of interesting things in here, including some that our hardware doesn't support, so take it with a grain of salt (it has flash & all kinds of stuff, pretty much a generic Qualcomm camera driver). Anyways, here are some of the interesting ones;
CAMERA_PARM_ISO, (duh)
CAMERA_PARM_APERTURE, (maybe change aperture speed for better shots?)
CAMERA_PARM_SHUTTER_SPEED, (better response time?)
CAMERA_PARM_HISTOGRAM, (not useful for me, but neat)
CAMERA_PARM_FPS_LIST, (this one is defined under a video section, maybe change frame rate??)
Neat huh?
Anyway, the really cool part is line 405-409:
typedef enum
{
CAMERA_AUTO_FOCUS,
CAMERA_MANUAL_FOCUS
} camera_focus_e_type;
Now I can't tell you what all this means, but I can read & tell you that that does say manual focus where it defines the options for focus type
Also, ISO options are; MAX, HIGH, DEBLUR, 100, 200, 400, 800. There are also some WB settings that we don't have available, here is the full list; AUTO, CUSTOM, INCANDESCENT, FLUORESCENT, DAYLIGHT, CLOUDY_DAYLIGHT, TWILIGHT, SHADE, MAX_PLUS_1. Most of those are available in the 1.5 HTC based camera apps, but twilight & shade aren't.
Actually speaking of the HTC camera, it does almost EVERYTHING mentioned in this code. It misses a few of them, as I said, but it has debanding, WB, brightness. It is just missing the ISO (different from brightness, I promise).
This is about all I know, that its REALLY interesting to look through, and that we should make a camera app that can use all this

Also, just to say in my last post, I DO know what all of those camera terms mean, I'm a photo buff, I just put them in terms that apply to the G1

Bump. Isn't there any other interest in this? I don't have the experience nor the time to do this, but I REALLY want it. I already looked at the code & did a writeup. Surely someone can do it...

Geniusdog254 said:
Bump. Isn't there any other interest in this? I don't have the experience nor the time to do this, but I REALLY want it. I already looked at the code & did a writeup. Surely someone can do it...
Click to expand...
Click to collapse
Hey Geniusdog254,
thanx for sharing your findings! I guess is just a matter of (spare) time. I'm personally (but slowly) trying to get into kernel building (and low-level dev in general) so to try these myself...
An already experienced and interested fellow dev would certainly help if he/she came forward

I am very interested in this as well. Has any progress been made?

lapalways05 said:
This would be awesome! Espcially for photographers like muah
Click to expand...
Click to collapse
If you are a photographer and rely on a phone camera something tells me oyu dont get much work.

My only advice at this point is to change the title of the thread to [Think Tank] camera manual focus... you'll get more devs to glance at it.

Request: rangefinder app.

I'm in need of a rangefinder, and was wondering, why not my always handy Leo?
Since it has a focusing function for the camera, it must have some sort of a sensor for measuring distance - or whatever algorithm it uses might be calibrated for actually displaying the(approximate) measured distance.
I would pay for a usable app.
Did a quick search of the Leo forum, no returns for "rangefinder".
Thanx

Cannot help you with a range finder tip, i don't think this is possible with a focusing camera, but why not google disto.

re
up you go!

re
one more time

FUN APP: HD2 Pilot Flight Display using GPS

!! FUN APPLICATION, NOT INTENDED TO BE USED IN REAL WORLD AVIATION !!
For all those flight-sim enthusiasts out there: I have created this PFD (primary flight display) which shows the speed, the altitude the coards and the attitude similar to a real PFD display in an airplane cockpit.
Although the application has been created and tested on an HTC HD2, it might work on other devices as well. Internel or external GPS and the HTC G-Sensor are required. It is planned to add a serial communication channel to a PC server component which allows to use this little proggy with MS Flight Simulator displaying the flight parameters so you can get rid of the cockpit panel on your primary display.
Just keep in mind that this is the first version of the program, so there might be *some* improvement potential.
A screenshot of the program is also attached.
Pls let me know what you think about it.
Thanks.

As a pilot I cannot find any sense in this, sorry m8.
Useless for aviation.
Useful might be an HSI-App, an RAIM-availability-check-App, a NOTAM-APP and so on. An artificial horizon on a handheld device... No, not good...

Title correction...
It is just for fun, not intended for real world aviation.
I will change the title so that it becomes more clear.

As an airbus pilot I like it! Lots of scope for further development, keep up the good work !

when I read your discrip, I had something totaly dif pictured in my mind. guess Im falling back on my sail plane lesson days.
I had round face dial and a yaw bubble pictured.
While this is cool, I would prefer to see the old analog style with an altimeter that you can set your start altitude and a yaw bubble, rather than the HUD style. just IMO.
And yes this is just for fun.
Keep it up, I will follow your project with intrest.
cheers

Good Work mate
While some are critical in their opinion I'm pleased with your app.
Keep up the good work mate and for all others who are not so encouraging ...... what do you want for an app a full blown flight simulator, the guys making an effort to develop something and sharing it for a free with us so to help him out at least .... I mean at least encourage him and make some constructive criticisms.
It doesn't cost to be nice and help to motivate others...........

Customize it
Just as a hint for those of you, who would want to use other bitmaps. I have designed the application in a way which allows you to modify or extend it. If you look into the applications program folder, you will find an XML file describing the layout of the display. You may also change or add bitmaps. The bitmaps are all located in the
HTML:
resources
subfolder. If you change the size of the offset of bitmaps, you will have to adjust some values in the XML file as well.
As you can see there all items are drawn in 3d space.
However, I am working on a HSI as suggested before. I will post it later this week.
Known issue:
- After running the application 3 or 4 times, OpenGL is not working properly anymore (not able to create rendering context). This is an issue of OpenGL. You have to restart your device for OpenGL to work again. If anyone has a solution, please let me know.

leihen said:
It is planned to add a serial communication channel to a PC server component which allows to use this little proggy with MS Flight Simulator displaying the flight parameters so you can get rid of the cockpit panel on your primary display.
Thanks.
Click to expand...
Click to collapse
That would be awesome!

Cool app
Certainly would be better than no attitude information in the event of a vacuum and/or elec failure.Even if just to make flying the performance instruments a bit easier.
I would defintely like to see a HSI app possibly with an open (editable)waypoint database.Anyone interested!?
Keep up the good work!

I love it. Thanks so much...
I just wonder if settings could be made permanent until being changed again so as to start the application without my having to select REAL and AVERAGE everytime.
And as a proud HTC HD2 owner, the display could me made much
larger indeed...
Congratulations and thanks again.

This is a fine app with a lot of potential esp. for UL-pilots as an emergency backup if UL-airplane-pfd fails.
Would be nice if indicators are bigger and the layout equals to Flymap, Skymap or MGL-layout
There is enough place for a nice big yaw indicator. Maybe You can get some code from GPS-tracker V2.0 (MooNah) in this forum, it already has a full working PFD incorporated.
Good luck with further devs., when next version is online I will try it in my gyroplane.

I think it's fun!!!!!
next step: build a flightsim for wm where we could use this

You will be in real danger....if you do so.
troed said:
This is a fine app with a lot of potential esp. for UL-pilots as an emergency backup if UL-airplane-pfd fails.
Would be nice if indicators are bigger and the layout equals to Flymap, Skymap or MGL-layout
There is enough place for a nice big yaw indicator. Maybe You can get some code from GPS-tracker V2.0 (MooNah) in this forum, it already has a full working PFD incorporated.
Good luck with further devs., when next version is online I will try it in my gyroplane.
Click to expand...
Click to collapse
As you will easily see, this PFD horizon responds to gravity, that is, to the accelerometers installed in the phone.
It has no gyros, no way to provide PITCH ATTITUDE, WHATSOEVER.
If you keep the phone perfectly vertical and quickly move forward (accelerate) it will SURELY show a pitch up...pretty much the same effects that a stand-by compass shows when changing speed (remember that?...accelerate-north, decelerate-south).
You will have the very same pitch information as the one given by a bottle full
af water suspended from a string, or a can of Coke : and it will KILL YOU as well as your passengers (if any), not to mention people on the ground.
The only usable parts of this FUN APP (as named by the author himself ) in aviation are:
1. True track (not magnetic heading).
2. Altitude (neither QNH, nor QFE related, but of course; unless your flying field happens to be at sea level and actual atmosphere matches the ISA atmosphere parameters exactly). Remember that QNH variations as well as heat will make the GPS readings very different to that of your altimeter, as height of the air column will vary a +/-4% every +/-10 degrees Celsius.
Example. Airplane flying at Flight Level 300. QNH in the area 1023. Terrain at 2000 feet. Atmosphere is ISA+15.
Therefore if we move the 1013.25 setting to 1023 there will be a reading increase from 30.000 feet to 30300 (calibrated altitude, QNH related).
That is 28.300 feet above ground (we start with this as the air column height for the calculation). Since ISA is +15 we add 15/10 times 4% and we have 28300*15/10*4/100= 1698. True altitude is 30300+1698=31988
So we are cruising at FL300, 30.000 feet pressure altitude, 30.300 feet calibrated altitude (QNH related), 31988 above sea level, 29988 feet above ground level.
GPS WILL SHOW 31988 FEET.
3. Ground speed ( neither IAS nor CAS nor EAS nor TAS), as provided by GPS system. Remember that your airplane aerodynamics are related to calibrated speeds....you will stall if too slow ore destroy the airframe if to quick !!!! But you can navigate and make good your track, of course.
Hope I have made myself understood....and that you read this at the earlier !!!

Hi!
It quite very good if the second part under we have the route. I am using the Oziexplore program, it can creates the route, and apear on screen. if this soft applied to that once, could be perfected!
Thanks

great app mate..just for fun...

Nice work thank you. On future can you make like pilot cocpit with all dash boards like in Flith simulator game if this possible. Thank you

leihen said:
!! FUN APPLICATION, NOT INTENDED TO BE USED IN REAL WORLD AVIATION !!
For all those flight-sim enthusiasts out there: I have created this PFD (primary flight display) which shows the speed, the altitude the coards and the attitude similar to a real PFD display in an airplane cockpit.
Although the application has been created and tested on an HTC HD2, it might work on other devices as well. Internel or external GPS and the HTC G-Sensor are required. It is planned to add a serial communication channel to a PC server component which allows to use this little proggy with MS Flight Simulator displaying the flight parameters so you can get rid of the cockpit panel on your primary display.
Just keep in mind that this is the first version of the program, so there might be *some* improvement potential.
A screenshot of the program is also attached.
Pls let me know what you think about it.
Thanks.
Click to expand...
Click to collapse
Indeed as an Ultralight-Gyroplane-Pilot I like this app and since the Horizon-tab in GPS-Tracker by MooNah doesn´t work right now this could be alternative as a a last resort-backup if glass-cockpit instruments (MGL-Avionics) fail ...... (better to have this than nothing at all and I also have Flymap PPC on my HD2 if main Moving map Nav. fails)
This app has great potential since it reads the infos from G-sensor and GPS.
For the future dev. if I might add my wishlist:
1. Add to screen: slide-indicator and compass, Altitude
2. slightly more refined graphics
As a start: BRAVO, hope You have the patience to go on developing this nice app ( like Dunc001, that made in 100s of hours of work a professional weather app - Duncans Weather Panel - see there - that is more reliable than many professional aviation weather briefings).
I bookmarked this thread and hope for further developments by U
Congratulations

like the Android solution ixGyro:
http://www.ixellence.com/index.php?option=com_content&view=article&id=227&Itemid=274&lang=de

JHimmelbauer said:
like the Android solution ixGyro:
http://www.ixellence.com/index.php?option=com_content&view=article&id=227&Itemid=274&lang=de
Click to expand...
Click to collapse
Jepp, EXACTLY THIS would be cool on the HD2 on WinMo (Android not running on mine) !!!!!!!!!!!!!!!!!!!!!!!!!

troed said:
Jepp, EXACTLY THIS would be cool on the HD2 on WinMo (Android not running on mine) !!!!!!!!!!!!!!!!!!!!!!!!!
Click to expand...
Click to collapse
a other solution for Windows Mobile is "Inclinometer77" -
visit http://forum.xda-developers.com/showthread.php?p=6677074
This App goes in the right direction, but unfortunately not to use without Gyro in a Plane, but a nice game for pilots ;-)
Happy Landings

[Q] About EMF - magnetic field and radiation detector

There are lots of apps that claim to detect magnetic fields (other calls ghost detector or metal detector)
How reliable or how much you can rely on the above applications?
Can it really measure any magnetic field / radiation ?
If so - what kind of fields can it measure?
Else - is it a bullshiat?
I want to buy a device that measure radiation low&high frequencies and also rely as much as it can - such as Cornet ED65/78..
There is any recommendations for something you can trust but not expensive?

Technically speaking, mobile phones are designed to detect electromagnetic wave (Usually radio frequencies). But usually smartphones have additional sensors such as a magnetometer, mainly to detect direction and point locations.
So some apps exploit this feature, but they're pretty much not that accurate due to interference and background noise, so pretty much not that reliable for scientific use per say.
Here is a good article that shed the light on the subject.
Unfortunately I'm not an expert in the "Applied Physics" field so I can't help you much in your search for a good EMF meter! But I know someone who knows someone who knows.

-
silv3rfox said:
Technically speaking, mobile phones are designed to detect electromagnetic wave (Usually radio frequencies). But usually smartphones have additional sensors such as a magnetometer, mainly to detect direction and point locations.
So some apps exploit this feature, but they're pretty much not that accurate due to interference and background noise, so pretty much not that reliable for scientific use per say.
Here is a good article that shed the light on the subject.
Unfortunately I'm not an expert in the "Applied Physics" field so I can't help you much in your search for a good EMF meter! But I know someone who knows someone who knows.
Click to expand...
Click to collapse
Thanks for the reply and the links! :good:
I search for mainly low freq - electrical devices at home, the "recommended" radiation is ~2mG so it need to be a bit sensitive/accurate. Also I don't want to spent a lot of money on this device that most of the time will be into the drawer..
I've found some of these measurer, hope to get some recommendation or focus on one [or other non on the list] of them:
1. EMF ELF Magnetic Field Meter = 30Hz~300Hz ~70.27$
2. TENMARS TM-191 30Hz~300Hz ~75$
3. EMF ELF Magnetic Field Meter = 30Hz~300Hz ~75.33$
4. Cornet ED25G = 100Mhz-3Ghz - 108.9$
5. Cornet ED65 = 100MHz-6GHz - 139.9$
6. TM-195 Tenmars 3 Axis 50MHz ~ 3.5GHz 149$
7. 3-Axis Gaussmeter EMF ELF = 30 ~ 2000 Hz - 155.9$

Figuring out Samsung Accesory Protocol internals

Hello,
I want to figure out the Samsung Accesory Protocol in order to create a "open source" Gear Manager app replacement. This thread is to ask if anyone has been trying to do the same thing as well as try to gather as much information about this protocol as possible. Generic discussion is also accepted, in case anyone has better ideas.
Right now all I know is that this protocol is based on RFCOMM, albeit it can be transported over TCP too. It has a level 1 "framing" which consists basically on
Code:
packed struct Frame {
uint16_be length_of_data;
char data[length_of_data];
}
packed struct FrameWithCRC {
uint16_be length_of_data;
uint16_be crc_of_length;
char data[length_of_data];
uint16_be crc_of_data;
}
I also know that there are various types of packets. "Hello" packets are exchanged early during the connection and contain the product name, etc. Authentication packets are exchanged right after the initial "hello" and contain some varying hashes (crypto warning!). Then the normal data packets are "multiplexed", as in usbmuxd: they have 'session' IDs which described towards which watch program they are talking with. All Hello and authentication packets are sent without CRC, but normal data packets are. The CRC implementation used is crc16, same poly as in the linux kernel.
I suspect that whatever we uncover about this protocol might be useful to e.g. pair Gear with an iPhone, with a PC, things like that.
Note: most of this comes from viewing Bluetooth logs. However it's clear that reverse engineering will be required for the cryptographic parts. In this case I believe it's legally OK to do so in the EU because it's purely for interoperability reasons. I don't want to create a competitor to the Gear2, I just want to talk to it.
Motivation: I bought a Gear2 in order to replace a LiveView that was dying (buttons wearing out, broken wriststrap clips, etc.) . I used it both for notifications as well as map/navigation.
Since I have a Jolla, no programs are available to pair with most smartwatches, but I've been developing my own so far (MetaWatch, LiveView). Thus I decided on a replacement based purely on hardware characteristics and price. Also Tizen seems more open than Android, thus I figured out it would be easier for me to adapt to the watch.
However it seems that I understimated the complexity of the protocol that connects the Gear with the GearManager. So my options in order to make use of this watch are:
Sell Gear2 back and buy something that's easier to hack (e.g. another LiveView ),
Figure out the SAP protocol and write a replacement Gear Manager app (what this thread is about),
Write replacement Tizen applications that don't use SAP. This involves writing new programs for Calls, Messages, Notifications, Alarms, Camera, watchOn, Pulse monitor, etc. i.e. a _lot_ of work if I want to exploit all features of the watch.
But at least one can reuse the existing Tizen settings app, launcher, drivers, etc. (I started porting Qt to the Gear2 with this idea)
Use a different Linux distro on the Gear 2. Such as Sailfish, Mer, etc. This involves all the work of option 3 + possibly driver work.
As of now I've not decided which option is easier for me so I'll keep trying to push them all.

javispedro said:
Hello,
I want to figure out the Samsung Accesory Protocol in order to create a "open source" Gear Manager app replacement. This thread is to ask if anyone has been trying to do the same thing as well as try to gather as much information about this protocol as possible. Generic discussion is also accepted, in case anyone has better ideas.
Right now all I know is that this protocol is based on RFCOMM, albeit it can be transported over TCP too. It has a level 1 "framing" which consists basically on
Code:
packed struct Frame {
uint16_be length_of_data;
char data[length_of_data];
}
packed struct FrameWithCRC {
uint16_be length_of_data;
uint16_be crc_of_length;
char data[length_of_data];
uint16_be crc_of_data;
}
I also know that there are various types of packets. "Hello" packets are exchanged early during the connection and contain the product name, etc. Authentication packets are exchanged right after the initial "hello" and contain some varying hashes (crypto warning!). Then the normal data packets are "multiplexed", as in usbmuxd: they have 'session' IDs which described towards which watch program they are talking with. All Hello and authentication packets are sent without CRC, but normal data packets are. The CRC implementation used is crc16, same poly as in the linux kernel.
I suspect that whatever we uncover about this protocol might be useful to e.g. pair Gear with an iPhone, with a PC, things like that.
Note: most of this comes from viewing Bluetooth logs. However it's clear that reverse engineering will be required for the cryptographic parts. In this case I believe it's legally OK to do so in the EU because it's purely for interoperability reasons. I don't want to create a competitor to the Gear2, I just want to talk to it.
Motivation: I bought a Gear2 in order to replace a LiveView that was dying (buttons wearing out, broken wriststrap clips, etc.) . I used it both for notifications as well as map/navigation.
Since I have a Jolla, no programs are available to pair with most smartwatches, but I've been developing my own so far (MetaWatch, LiveView). Thus I decided on a replacement based purely on hardware characteristics and price. Also Tizen seems more open than Android, thus I figured out it would be easier for me to adapt to the watch.
However it seems that I understimated the complexity of the protocol that connects the Gear with the GearManager. So my options in order to make use of this watch are:
Sell Gear2 back and buy something that's easier to hack (e.g. another LiveView ),
Figure out the SAP protocol and write a replacement Gear Manager app (what this thread is about),
Write replacement Tizen applications that don't use SAP. This involves writing new programs for Calls, Messages, Notifications, Alarms, Camera, watchOn, Pulse monitor, etc. i.e. a _lot_ of work if I want to exploit all features of the watch.
But at least one can reuse the existing Tizen settings app, launcher, drivers, etc. (I started porting Qt to the Gear2 with this idea)
Use a different Linux distro on the Gear 2. Such as Sailfish, Mer, etc. This involves all the work of option 3 + possibly driver work.
As of now I've not decided which option is easier for me so I'll keep trying to push them all.
Click to expand...
Click to collapse
I think your thread should probably go in the Dev section for Tizen. Have you made any development? If your want it moved, report your own post with the button in top right labeled report. You can then suggest your thread be moved to the new Tizen Development section. Ok, I wish you all the luck, you seem to be very talented programmer/dev. Thanks for your contributions.
Chris

noellenchris said:
I think your thread should probably go in the Dev section for Tizen.
Click to expand...
Click to collapse
Well, some mod already moved this thread from Development, where I originally posted it, into Q&A. This is not exactly "Tizen" development (SAP is used in may Samsung devices seemingly).
noellenchris said:
Have you made any development?
Click to expand...
Click to collapse
Yes, lots of progress. I have been able to write a program that connects to the Gear2 from my PC, succesfully "completes" the setup program and synchronizes the date&time. Things like changing the background color etc. are now trivial. I will soon port it to my Jolla.
I am now looking into how to send notifications to the watch. I've not been able to get Gear Manager to actually send any notifications (to use as "reference"), because goproviders crashes when I try to simulate notifications on my android_x86 VM
If anyone can send me an HCI / Bluetooth packet capture of their Android device while it is sending notifications to the Gear2 I would really appreciate it.
Unfortunately, the main problem here is that Samsung uses some cryptographic authentication as a form of "DRM". I am not exactly sure why.
There was no way for me to discover how the crypto worked so I took the unclean approach and dissasembled their crypto code (libwms.so). That means there's no way I would be able to distribute the code now without risking a lawsuit from Samsung.
Sadly this means that while I can distribute the protocol specifications I obtained, legally distributing "Gear Manager replacements" is probably impossible.

javispedro said:
Well, some mod already moved this thread from Development, where I originally posted it, into Q&A. This is not exactly "Tizen" development (SAP is used in may Samsung devices seemingly).
Click to expand...
Click to collapse
Ya, I was kinda in a Gear 1 mind set, and they have separate threads for Android and Tizen....
Chris

javispedro said:
Unfortunately, the main problem here is that Samsung uses some cryptographic authentication as a form of "DRM". I am not exactly sure why.
There was no way for me to discover how the crypto worked so I took the unclean approach and dissasembled their crypto code (libwms.so). That means there's no way I would be able to distribute the code now without risking a lawsuit from Samsung.
Sadly this means that while I can distribute the protocol specifications I obtained, legally distributing "Gear Manager replacements" is probably impossible.
Click to expand...
Click to collapse
I would gladly write a MIT-licensed C library implementing your protocol specifications. That would be correctly following the chinese-wall approach to reverse-engineering, right?
Anyway, AFAIK, being in Europe decompiling for interoperability purposes is allowed -- I know that wikipedia is not to be taken at face value, but: en.wikipedia.org/wiki/Reverse_engineering#European_Union

Antartica said:
I would gladly write a MIT-licensed C library implementing your protocol specifications. That would be correctly following the chinese-wall approach to reverse-engineering, right?
Anyway, AFAIK, being in Europe decompiling for interoperability purposes is allowed -- I know that wikipedia is not to be taken at face value, but: en.wikipedia.org/wiki/Reverse_engineering#European_Union
Click to expand...
Click to collapse
Well, the problem is not the protocol specifications per se, which I'm actually quite confident I'd be able to redistribute (I'm in EU). The problem is the cryptography part, which is basically ripped off from the Samsung lib "libwsm.so" . Unless we can find out what cryptographic method that lib uses, distributing alternate implementations Is a no-go.

javispedro said:
Well, the problem is not the protocol specifications per se, which I'm actually quite confident I'd be able to redistribute (I'm in EU). The problem is the cryptography part, which is basically ripped off from the Samsung lib "libwsm.so" . Unless we can find out what cryptographic method that lib uses, distributing alternate implementations Is a no-go.
Click to expand...
Click to collapse
If you have the time, I don't mind researching the possible crypto used (although I've only studied DES/3DES, AES and Serpent, hope that whatever scheme used is not very different from them).
Some ideas to start from somewhere:
1. As you have used its functions, it is a block cipher? I will assume that it is.
2. What is the key size and the block size?
3. Are there signs that it is using a stack of ciphers? (that is, applying one cipher, then another to the first result and so on)

Antartica said:
If you have the time, I don't mind researching the possible crypto used (although I've only studied DES/3DES, AES and Serpent, hope that whatever scheme used is not very different from them).
Some ideas to start from somewhere:
1. As you have used its functions, it is a block cipher? I will assume that it is.
2. What is the key size and the block size?
3. Are there signs that it is using a stack of ciphers? (that is, applying one cipher, then another to the first result and so on)
Click to expand...
Click to collapse
Hello, I've not forgotten about this, just somewhat busy and been using the MetaWatch lately
1. Yes it is clearly a block cipher, and the block size Is 16bytes.
2. I don't know about the key size, it is obfuscated.
3. Doesn't seem like a stack of ciphers. It looks like some overcomplicated AES. But to be honest AES is the only encryption I know of
By the way I think I will upload my current test "manager" source code to somewhere after removing the crypto specific files . Since the protocol itself has been obtained cleanly. Note I've used Qt (not the GUI parts) so it's useless for creating a library; the code will probably need to be rewritten to do so, but it may be useful as "protocol specs".

javispedro said:
Hello, I've not forgotten about this, just somewhat busy and been using the MetaWatch lately
Click to expand...
Click to collapse
No problem. Curiously, I've transitioned from the metawatch to the Gear1 fully (null rom, not pairing with bluetooth to the phone but gear used as a standalone device).
[off-topic]I'm not using my metawatch anymore. I was modifying Nils' oswald firmware to make it prettier and to have some features I wanted (calendar, stopwatch), but it was very inaccurate, supposedly because of missing timer interrupts (the existing LCD drawing routines were too slow). I rewrote the graphics subsystem just to stumble into a known mspgcc bug, and trying to use the new redhat's mspgcc resulted in more problems (memory model, interrupt conventions). In the end I couldn't commit enough time to fix that and my metawatch is now in a drawer[/off-topic]
Returning to the topic:
javispedro said:
1. Yes it is clearly a block cipher, and the block size Is 16bytes.
Click to expand...
Click to collapse
Good. We can at least say it isn't DES/3DES nor blowfish (64 bits block size). Regrettably there are a lot of ciphers using 128-bits block size; that I know: AES, Twofish and serpent.
Perusing the wikipedia there are some more of that size in use: Camellia, sometimes RC5 and SEED.
javispedro said:
2. I don't know about the key size, it is obfuscated.
3. Doesn't seem like a stack of ciphers. It looks like some overcomplicated AES. But to be honest AES is the only encryption I know of
Click to expand...
Click to collapse
I understand that to mean that you cannot use that library passing your own key, right?
What a pity! One way to test for these ciphers would have been to just cipher a known string (i.e. all zeroes) with a known key (i.e. also all zeroes) and compare the result with each of the normal ciphers :-/.
javispedro said:
By the way I think I will upload my current test "manager" source code to somewhere after removing the crypto specific files . Since the protocol itself has been obtained cleanly. Note I've used Qt (not the GUI parts) so it's useless for creating a library; the code will probably need to be rewritten to do so, but it may be useful as "protocol specs".
Click to expand...
Click to collapse
Perfect. I don't need anything more .

Ok, so I've uploaded my SAP protocol implementation: https://git.javispedro.com/cgit/sapd.git/ . It's "phone" side only, ie it can be used to initiate a connection to the watch but not to simulate one. In addition, it's missing two important files: wmscrypt.cc and wmspeer.cc which implement the closed crypto required to "pair" the watch. The most important file is sapprotocol.cc which implements the packing/unpacking of the most important packet types. The license of those files is GPLv3 albeit I'm very happy if you use the information contained on them to build your "Gear Manager" program under whichever license you'd prefer.
For anyone who hasn't been following the above discussion: I've figured out a large part (useful for at least establish contact with the watch and syncing time/date) of the SAP protocol used between the Gear watch and the Gear manager program on the phone. This has been done mostly by studying traces and afterwards talking to the watch using my test implementation above to figure out the remaining and some error codes. The debug messages left by the watch's SAP daemon were also immensely helpful. As long as I understand this is perfectly safe to do, publish and use as I'm in the EU and is basically the same method Samba uses.
Unfortunately, the protocol contains some crypto parts required for the initial sync (subsequent connections require authentication). However, the communication itself is not encrypted in any way, which helped a lot with the process. Because it's impossible for me to figure out whatever authentication method is used, I had to disassemble the library implementing this stuff (libwms.so). This is still OK according to EU law, but I'm no longer to release that information to the public. I'm looking for alternatives or ideas on how to handle this fact.
In the meanwhile, let's talk about the protocol. It's basically a reimplementation of the TCP(/IP) ideas on top of a Bluetooth RFCOMM socket. This means that it's connection oriented and that it can multiplex several active connections (called "sessions") over a single RFCOMM link. Either side of the connection can request opening a connection based on the identifier of the listening endpoint (called a "service"). Strings are used to identify services instead of numeric ports as in TCP. For example, "/system/hostmanager" is a service that listens on the watch side. Once you open a session towards this service (i.e. once you connect to it) you can send the time/date sync commands. In addition to be the above the protocol also seems to implement QoS and reliability (automatic retransmission, ordering, etc.). It's not clear to me why they reimplemented all of this since RFCOMM is a STREAM protocol, and thus reliability is already guaranteed!! So I've not focused much on these (seemingly useless) QoS+reliability parts of the protocol.
Let's start with the link level. There are two important RFCOMM services exposed by the watch: {a49eb41e-cb06-495c-9f4f-aa80a90cdf4a} and {a49eb41e-cb06-495c-9f4f-bb80a90cdf00}. I am going to respectively call those two services "data" and "nudge" from now on. These names, as many of the following ones, are mostly made up by me .
The communication starts with Gear manager trying to open a RFCOMM socket towards the "nudge" service in the watch. This causes the watch to immediately reply back by trying to open a connection to the "data" service _on the phone_ side. So obviously this means that your phone needs to expose the "data" RFCOMM service at least. In addition, the watch will try to open a HFP-AG connection (aka it will try to simulate being a headset) to your phone. Most phones have no problem doing this so no work is required. Of course, if your phone is a PC (as in my case ) then you'll need to fake the HFP profile. I give some examples in my code above (see scripts/test-hfp-ag and hfpag.cc).
Once the RFCOMM socket from the watch to the phone "data" service is opened, the watch will immediately send what I call a "peer description" frame. This includes stuff such as the model of the watch as well as some QoS parameters which I still don't understand. The phone is supposed to reply back to this message with a peer description of its own. See sapprotocol.cc for the packet format.
After the description exchange is done, the watch will send a "authentication request" packet. This is a 65 byte bigint plus a 2 byte "challenge". The response from the phone should contain a similar 65 byte bigint, the 2 byte response, and an additional 32 byte bigint. If correct, the watch will reply with some packet I don't care about. Otherwise the connection will be dropped. It obviously looks like some key exchange. But this is the crypto part that's implemented in libwms.so....
After these two exchanges link is now set up. The first connection that needs to be opened is towards a service that is always guaranteed to be present, called "/System/Reserved/ServiceCapabilityDiscovery". It is used by both sides of the connection to know the list of available services present on the other side. Despite this, you cannot query for all services; instead, you must always know the name of the remote service you're looking for. There's some 16-byte checksum there which I don't know how to calculate, but fortunately the watch seems to ignore it!! I suspect that you're expected to actually persist the database of available services in order to shave a roundtrip when connection is being established. But this is not necessary for normal function. This service is implemented in capabilityagent.cc, capabilitypeer.cc . This part was actually one of the most complex ones because of the many concepts. I suggest reading the SDK documentation to understand all the terms ("service", "profile", "role", etc.).
If everything's gone well, now the watch will try to open a connection to a service in your phone called "/system/hostmanager". Once you get to this message things start to get fun, because the protocol used for this service is JSON! It's implementation resides in hostmanageragent.cc, hostmanagerconn.cc . For example, Gear Manager sends the following JSON message once you accept the EULA: {"btMac":"XX:XX:XX:XX:XX:XX", "msgId":"mgr_setupwizard_eula_finished_req", "isOld":1}. At this point, the watch hides the setup screen and goes straight to the menu.
Well, this concludes my high-level overview of the SAP protocol. Hope it is useful for at least someone!
Things to do:
Personally I'm looking for some traces of the notification service. Ie the one that forwards Android notifications towards the watch. For some reason it doesn't work on my phone, so I can't get traces. I suspect it's going to be a simple protocol so a few traces will be OK. It's the only stuff I'm missing in order to be able to actually use the Gear as a proper smartwatch with my Jolla.
We still need to tackle the problem of the cryptographic parts. Several options: either "wrap" the stock libwms.so file, try to RE it the "proper way", .... I'm not sure of the feasibility of any of these.
Many other services.

javispedro said:
After the description exchange is done, the watch will send a "authentication request" packet. This is a 65 byte bigint plus a 2 byte "challenge". The response from the phone should contain a similar 65 byte bigint, the 2 byte response, and an additional 32 byte bigint. If correct, the watch will reply with some packet I don't care about. Otherwise the connection will be dropped. It obviously looks like some key exchange. But this is the crypto part that's implemented in libwms.so....
Click to expand...
Click to collapse
About that 65-byte bigint... that is a 520-bit key. The usual length of ECDSA keys is exactly 520-bits, so we may have something there: it is possible that they are using ECDSA signing (just like in bitcoin, so there are a lot of implementations of that code).

Not forgotten about this!
Just an status update:
I'm still in the process of defining the API of the C library using javispedro's sources as template.
It's tougher than I originally supposed because the C++ code has a lot of forward-declarations of classes, which is very difficult to map into C. To counter that I have to move elements between structures and I'm not so comfortable with the codebase yet.
And then there is still the hard work of translating the Qt signals/slots to plain' old callbacks... and implementing the bluetooth part using bluez API... and... well, I hope that is all.
Anyway, patience .

I've now had access to a Samsung S2 and thus I have been able to obtain more traces. The latest Git now contains code to connect to the notification manager service, thus allowing to send notifications from the phone to the watch.
That was the last missing part to be able to use the Gear 2 as a 'daily' smartwatch with my Jolla, so I've now also ported the code to run under Sailfish. In fact I'm using this setup at the moment. My first comment is "wow the vibrator IS weak".
You can find a log of sapd's (ie my code) startup qDebug() messages; they may be useful (if you can't yet get your code to run)
I suspect that there may still be some important battery issues because the watch keeps printing error messages about SAP services it can't find on the phone (and instead of sleeping, it starts busy polling for them.... :/ ). It does not seem to happen while the watch is out of the charging cradle, so it may not be important, but not sure yet.
As for the encryption, I'm not sure how to proceed. I could describe the code to you, but that would be risky, because I don't understand what it does. Thus the only way (for me) to describe it would be to pass on the mathematical formulas/pseudocode ... Apart from that, we also have the problem of the keys...
Antartica said:
The usual length of ECDSA keys is exactly 520-bits, so we may have something there: it is possible that they are using ECDSA signing
Click to expand...
Click to collapse
They do use ECDH indeed, and they link with OpenSSL and import the ECDH functions. However it's not clear if they use ECDSA; while the crypto algorithm DOES resemble DSA, I cannot fully identify it.

Congratulations for managing to make it work with the Jolla .
I have finally found a suitable "flattened" class hierarchy as to be able to map your code into C; see the attachs. Basically, I have to move the functionality of SAPConnectionRequest, SAPSocket, CapabilityPeer and SAPConnection into SAPPeer, and then it is suitable for my needs.
javispedro said:
As for the encryption, I'm not sure how to proceed. I could describe the code to you, but that would be risky, because I don't understand what it does. Thus the only way (for me) to describe it would be to pass on the mathematical formulas/pseudocode ... Apart from that, we also have the problem of the keys...
They do use ECDH indeed, and they link with OpenSSL and import the ECDH functions. However it's not clear if they use ECDSA; while the crypto algorithm DOES resemble DSA, I cannot fully identify it.
Click to expand...
Click to collapse
If you manage to describe it using mathematical formulas as in
http://en.wikipedia.org/wiki/Ellipt...ture_Algorithm#Signature_generation_algorithm
it would be perfect, but I reckon that to be able write that you need intimate knowledge of the code and don't know if you have time for that :angel:
And identifying the hash function used would be a problem in itself...
One idea: how about a ltrace so we have the calls to the openssl library? That may uncover new hints.
Anyway, I have a lot of work before me until I need that, so don't fret over it.

Hi there! Any chance that the Gear can (really) work with an iPhone?

gidi said:
Hi there! Any chance that the Gear can (really) work with an iPhone?
Click to expand...
Click to collapse
agreed. Needs iPhone support please.

Antartica said:
Congratulations for managing to make it work with the Jolla .
I have finally found a suitable "flattened" class hierarchy as to be able to map your code into C; see the attachs. Basically, I have to move the functionality of SAPConnectionRequest, SAPSocket, CapabilityPeer and SAPConnection into SAPPeer, and then it is suitable for my needs.
Click to expand...
Click to collapse
You may want to look at the official Samsung SDK docs to match their class hierarchy. I tried to match my hierarchy to theirs, but this happened very late in the development process, so there is some weirdness.
Antartica said:
One idea: how about a ltrace so we have the calls to the openssl library? That may uncover new hints.
Click to expand...
Click to collapse
I more or less know what it is doing with OpenSSL, but that's because I looked at the dissassembly. They use OpenSSL for key derivation (ECDH), but the actual cryptographic algorithm is their own. This 'block cipher' is the part they have tried to obfuscate. Not much, but still enough to require more time than what I have available It is basically a set of arithmetical operations with some tables hardcoded in the libwsm.so binary, so no external calls to any library. The hardcoded tables are probably derivated from their private key, which is most definitely not on the binary. In fact I suspect this is basically AES with some changes to make it hard to extract the actual key used, so that's where I've centered my efforts.
Technically it should not even be copyrightable, so maybe I could just redistribute my C reimplementation of the algorithm, but as with any other DRM who knows these days... and that still leaves the problem of the tables/"private key".
Digiguest said:
agreed. Needs iPhone support please.
Click to expand...
Click to collapse
Well you are welcome to implement one such iPhone program yourself. Will be happy to resolve all the protocol questions you have.
(But please stop with the nagging).

Wasn't nagging at all. Just agreeing with him. I am no programmer so I have to rely on others for answers. Sorry if you thought otherwise.
Looking for to see more work on it though. Keep it up.

Hi there! Nice work on getting Gear2 to work with Jolla.
I'd love to get Gear1 to work with WP8.1. Do you have the code for Jolla
on github/bitbucket so I could give it a peek? Thanks in advance.

Duobix said:
Hi there! Nice work on getting Gear2 to work with Jolla.
I'd love to get Gear1 to work with WP8.1. Do you have the code for Jolla
on github/bitbucket so I could give it a peek? Thanks in advance.
Click to expand...
Click to collapse
javispedro had the sources in gitorius, but they are not there anymore (surely related to gitlab buying gitorius).
I attach a tarball with javispedro sources as of 19 October 2014.
Note that it lacks the files implementing the crypto, so just porting it is not enough to be able to communicate to the gear. OTOH, I know that there are some differences in the protocol between the Android Gear1 and the Tizen Gear2 (if the gear1 has been updated to Tizen, it uses the same protocol as gear2). Specifically, to be able to communicate with both watches, the gear manager package has both gear manager 1.7.x and gear manager 2.x. javispedro's code implements the gear 2 protocol.
Personally, I have my port on hold (I have problems with bluetooth in my phone, so there is no point in porting sapd right now as I would not be able to use it).