I am putting forward the following premise:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
"You can enjoy the joys and wonder of Android without spending a fortune...!"
I now intend to see if this is true!
Thread Purpose:
Provide a discussion area for those of us who are financially impaired, like myself, but want to experience the joys and wonders that tablets and android might hold...
At the moment the thread may also touch on android on mini-tablets (which might also make calls...) and larger tablets (with keyboards...hdds...lcd monitors etc) simply because on a shoestring budget you have to make do with what you have.
I hope to explore ways in which you can use Android it in new and interesting ways without paying out massive amounts on expensive hardware.
I'm not sure if it is totally achievable or not, but I'm sure it will be interesting to find out what you can do for less compared to the expensive options which are out there.
Idea's, comments, thoughts, discussions are all welcome.
The more unusual and interesting the better!
Thread Structure:
This first post will provide an index and links to the main discussion points/topics on the thread.
[Will see how this works!]
Periodically I shall post a new topic to discuss.
23March2011 - Topic One : Show Me The Droid
Method One: Using your existing laptop or PC
Method Two: Using the android emulator (also on your existing laptop or PC)
Method Three: Using your existing phone
29March2011 - Topic Two : A Low Cost Tablet
Part One: Justifying the purchase
Part Two: Android From The Box
Part Three: Passing the grade? (A-E)
Part Four: Passing the grade? (Continued...F-J)
12April2011 - Topic Three : Low Level Basics
Part One: Oh ADB Debugger!
Part Two: The Root Of It All
Part Three: Backups, ROMs and Flashbacks
Part Four: First Time Flasher! (added 1stAug11)
27June2011 - Topic Four: Low Level Interfacing
Part One: Android RS232 I/O
22Sept2011 - Topic Five: Development Tools & Tricks
Part One: Screenshots & Remote Control
Part Two: Scripts & Shortcuts
Side Topics
04May2011 - Side Topic: The Future! Quad core and beyond
02June2011 -Side Topic: Multi-Touch Technology - with No Touch Screen!
Q&A:
crevlthe: Are most apps up-sized to fit the resolution of tablets?
[I'll keep updating this thread every few days]
- please post comments, thoughts and ideas anyway, particularly if topic related.
I would love to hear about peoples thoughts and ideas
(simply reference Topic X:Method X/Step X etc if you want to comment on one item in particular).
Enjoy!
Small Print:
For the following posts I shall try to reference the source websites where possible, however apologies if I get this wrong, please feel free to pm me or post on the thread with any corrections and I'll amend the entry. Regarding images, where possible I shall try to use my own images, but at times this may not be possible. If you find I have used your image and you do not wish it to be used, then simply let me know and I'll change it. Where possible I shall state where the images have come from.
Clearly, the details in the thread are purely discussion and while I try to make them as accurate as possible I can not guarantee this. Damage or loss may occur by following some/all of the instructions, so if you do, do with care and at your own risk, I take no responsibility for your actions.
Topic One : Show Me The Droid
Before you can do anything with Android, you probably want to see it!
This topic will outline various ways you can "get at the driod" without spending anything.
Method One: Using your existing laptop or PC
This was the first way I got to play with Android (a long while ago), and that is using an Android live CD. I used something similar to the live CD from http://www.android-x86.org/ (images taken from site), which allows you to boot your computer with Android.
You can burn the image on to a CD/DVD and boot it cleanly or you can use a virtual machine and boot within that.
With a little bit of legwork, and a compatible computer you can boot from a USB key so you can carry your droid with you.
You can even install it, even dual boot, if you are brave!
While this is a simple and very cheap option (at most it should cost a CD/DVD to burn on), there is one slight problem...most computers don’t have touch, gravity sensors etc etc!
You have a number of options if you are seriously wanting to use this more:
1. You can continue to use the mouse (at least they seem to have a cursor now!)
2. You could probably make use of a large touch-pad (can be expensive, but cheaper ones are around)
3. If you have a small screen you could try adding a touch screen (8-10” touch screen overlay can be quite cheap but you will need to install it yourself and that can be tricky and will risk damage).
Perhaps this method could be interesting to try out as a low cost GoogleTV platform, but there would need to be some work done regarding the control method. Someday I may look into this option in more detail...
Microsoft Kinect not been plugged into to android yet???
Anwser: Yes it has! Ok, shame I don’t have one.
Topic One : Show Me The Droid
Method Two: Using the android emulator (also on your existing laptop or PC)
Of course for the developers out there, there is always the Android emulator which comes as part of the Android development package. Each time Android update the SDK (software development kit) for the latest release of Android, the emulator is updated to run the newest version of Android (this is often the source of early ROMs).
This does allow you to play with the latest Android version as soon as it is out, so you can get a feel for what features are improved etc and you can try out different versions to get an idea about the differences between them. You don't even need to install anything more than the Android emulator SDK if you don't want to write any code, as you can run the emulator separately to the development environment.
However, not only does this have similar control issues (except maybe that you get “soft-buttons”) but it is quite slow even on a fast machine.
(Click Image For Larger Version)
The advantage of course is it opens up a whole world of development options. The google developer site provides instructions for getting set up. Once you’ve jumped through the hoops, you can try it out by having a go at the various tutorial applications.
(Click Image For Larger Version)
Again this is something I may look at in more detail another time (such as getting setup, exploring what you can do with it and perhaps some simple development steps).
Topic One : Show Me The Droid
Method Three: Using your existing phone
You might just have that elusive Android device already, you just don't know it yet!
Clearly this option will vary wildly on the type of device you have and how in-depth you are willing to go. I’ve not managed to find a full list of devices which do support running android but it is safe to say that the “list” is growing all the time.
For me, my Phone is a Windows Mobile Phone, the HTC Blackstone, it’s quite an old device (in relative terms) but it has a good screen (3.8", 480 x 800) and modest processor (528 MHz ARM 11).
Fortunately for me, the XDAndroid group support this device, so I was able to make use of one of the many Android builds on the forums. I’m not quite sure what the current status is of this project, it seems although device specific threads have stopped, there are Android builds going up to 2.2.3...which I’ve had working on my device.
For the blackstone, running android is fairly pain free, since you install the files to your sd-card and if things don’t work out, you just delete them. One key component I required, was ditching (swapping) my class-6 SD card for a slower one (yes, slower!), once I’d switched to a class-2 one, android was up and running nicely.
(Click Image For Larger Version)
However, don’t get too excited yet, as many of the builds will have features which don’t work yet, such as Bluetooth support, camera and in-call voice (you can spend a long time getting the right mix of files for your device to get all these working) and many 3D accelerated games won't work. A lot of progress is being made here (I’ll go into this in more detail another time). Some issues you can live with and some you can’t. Also, if your device (like mine) is not a total powerhouse then you can expect things to run at less than optimal speed. Overall, don’t expect to be replacing your OS with an all singing all dancing Android one this way, unless you have decent device to start with.
All is not lost! By using one of the many dual-boot apps (they simply show a splash screen as soon as possible on power up) allow you to quickly select between your normal Windows Mobile OS and the Android one.
i.e. Gen.Y DualBoot by yozgatg
(Click Image For Larger Version)
This means you can keep a build of Android (or several if you wish) on your SD card and have a play with Android from time to time.
Personally I think this is an excellent option, even if the results aren’t perfect and it’ll probably cost you a fair bit of time experimenting, but the results are totally worth it.
I might revisit this in more detail if people would like me to. Hopefully I can learn a little more about the internals of how it fits together and provide a post on that.
For HD2 users (and some other phones), who are just too spoilt for choice, they can also install Android to their NAND (internal memory). This means they can totally replace the Windows Mobile OS on their system with Android, and because the device is fast, it apparently runs well enough to do so.
Topic Two : A Low Cost Tablet
Part One: Justifying the purchase
First off, the most important bit for this topic, how much does it cost?
I managed to get (buy) it for $90 (£56), including free shipping (limited time special offer).
Note:
I would not recommend this tablet at it's "normal" price of $130, since there are other tablets in that price range which are clearly better.
However, for me, the lower price was key here.
To put it in perspective, the Samsung Tab 7 Inch was £500 here - or $800!
The specs:
Code:
Model: Haipad M701
CPU: Telechip Tcc8902, 800MHz (ARM11)
OS: Android 2.1
RAM: 256MB
ROM: 2GB
Screen: 7 Inch Resistive (800 x 480px)
Ext Ports:
9v Supply
3.5mm Audio
Mini Usb (OTG Host) - hopefully will support Mass Storage devices
HDMI
TF (MicroSDHC)
Size: 192 x 114 x 15mm
Weight: 330g
Extra Details:
Gravity Sensor
Android Market
Adobe Flash (not supported)
Camera 0.3Mp
Wifi 802.11 b/g
My thought process regarding the purchase is this:
1. I really want an Android tablet, I’ve been look at them for months (in fact probably just after the iPad came out). In all that time I’ve lusted after tablet after tablet, but each time it came down to the cost, and the fact that I simply did not have $200/$250/$300 laying around. Throughout that period the number of tablets available have ballooned, the capabilities and specs too. I found myself looking at the affordable tablets, and then looking at the next one up (hdmi), then the next one (10” screen) and then the next one (multi-touch), until I’d priced myself out of my purchase.
2. With the advent of the tegra chips and honeycomb, the price of admission has been bumped slightly (I’d say you are starting at $300 for a low end one (quality of the screen/touch is be compromised - Advent Vega)) - previous to that an A8 based tablet, such as the A81 for around $200-250 was a good deal. To be a serious contender for anything which comes after honeycomb (for the tablet branch), and gaming platform that is developing (of which Cordy is the thin end of the wedge), the power step provided by the Tegra family is a must.
3. Back when I first started looking at tablets, I was in fact considering a very similar device (the X10 and the G10, of which the Haipad M701 is fairly similar).
4. Aside from wanting to use the latest and greatest releases from Android and games etc, there is a need for more modest requirements to be met. Can a basic tablet do this, I intend to find out?
These "modest" potential uses would be:
A: Replace/supplement a poorly designed portable Toshiba DVD player for in-car use, which in my opinion was probably the worst product I’ve ever purchased (despite the quite promising spec sheet) - although obviously I may need to revise this status soon!
B: A Doodle pad, something which my phone gets commandeered for quite often by my off-spring. So a slightly larger screen would be useful for this.
C: Simple Web-browser, most of the time only a quick check on the web is needed, so this may be more helpful than firing up the laptop (which being a work one, dislikes my wifi and network most the time).
D: Music player, either from connected memory for in the car or perhaps from the network.
E: eReader, I’ve read a few books on the Blackstone’s 3.8" screen, so a larger screen would be helpful.
F: Require a device with camera and HDMI at minimum, since this will hopefully provide more options to experiment with (1st build of Android on the blackstone, didn’t have camera support which ruled out things like google goggles etc).
G: USB Host (mass storage), I am hoping that the device will allow me to use external storage devices via the usb, this would be very handy for dealing with camera pictures and videos etc.
H: USB Device keyboard support, I find it very annoying that the Blackstone has no h/w keys, this seriously limits what you can do with it (such as emulation programs etc) as there is no easy way to control things.
I: RS232 Support: Although I seriously doubt it, it would be really useful to get RS232 monitoring running on the device.
J: A development platform for writing android software on and to learn about android.
In Summary:
Overall, aside from the video/USB requirements, I hope that I am not being too ambitious for this device, but clearly I probably am. If/Once I get the device, I shall evaluate it against these requirements and also see what other uses I can put it to. I don’t expect the device to manage all of the uses above (particularly out-the-box), but hopefully it an fulfill at least some of them (even if it takes some custom firmware/modding or even some custom hardware to achieve this) I shall be happy.
For all I know, the tablet may well never turn up...and if it does it could be next to useless (i.e. next to that Toshiba DVD player...). As it happens, one review of a similar device was “expensive paper weight”, I’d estimate it about the weight of a medium sized cup of coffee (without the cup), so might be useful for when we get the fans out in the office this summer.
My purchase timeline:
Purchased tablet on 17th March (estimated delivery 10 working days).
Item shipped on 18th March (estimated shipping 15-20 days).
“Departure from outward office of exchange” 22nd March - Left the source country.
Received item 28th March!
Overall Delivery time: 11days (7 working days).
In return for the excellent shipping, I can say that the item was from PandaWill.
Out of the box review coming soon!
Thread has moved from "General" to it's new home in "Android Software and Hacking General". At first I didn't plan for it to be Android exclusive but as it turns out, it is, so hello to all on this thread.
I am very new to Android, so please be kind!
I hope this thread can be a beginners introduction of some kind, let me know if there are errors or if you would like more information on parts etc.
Regards.
Topic Two : A Low Cost Tablet
Part Two: Android From The Box
Packaged in a retail box:
(Click Image For Larger Version)
- Tablet (thankfully)
- 9volt 1.5Amp Output Power Supply (US plug)
- US to UK plug adaptor (a nice touch, clearly they take notice of the shipping address)
- 2x USB Cable (mini USB to USB male, short mini USB to USB female)
- Basic set of ear phones
- Product dimensions measure exactly as stated in the spec (I’d previously printed out picture of the screen to 1:1 scale based on the measurements).
Although I didn’t expect to get an HDMI cable, I didn’t expect the HDMI port to be a mini one, so it would have been helpful to have included one here (or at least an adaptor).
(Note: The USB car adaptor is not for it and did not come with it, but I thought it helps as a guide for size - it won’t charge by USB).
Charging:
(Click Image For Larger Version)
The first thing I did was to plug the tablet in for a charge, there are two reasons for this. Firstly to check that the power supply is functional and safe (i.e. does not over heat) and secondly for the battery.
If the battery is at a low level, you have to treat it carefully - particularly if was in storage (as it will gradually lose charge over time). Li-ion batteries if drained below their bottom limit, will “crash” their voltage, this causes a lot of damage to the battery and it may never recover fully (or in attempting to do so it may cause excess heat == bad news). You should always avoid switching any device on when the battery is in this state, so always charge just in case before trying to switch on (most electronics should refuse to turn on, but best not to count on it).
For this reason I was pleased to find that the battery was charged to approximately 60-80% (I guess) which is around the recommended storage/shipping level. Also the charger or tablet did not burst into flames, which was nice too!
Turned On:
Switching on the device, immediately the screen shows a colourful splash screen, then some linux penguin/mole, before displaying the normal android boot. Instantly I am pleased that the screen is working! I am also impressed that the screen quality, brightness and colour look quite good.
(Click Image For Larger Version)
60 Seconds later and Android has booted!
I would be interested to know if this is particularly fast or slow (my only comparison is booting the Blackstone Android from SD, which takes about 4 mins). For me, 1 min seems fast enough, certainly as fast as starting windows mobile. For normal use, the device can be put to sleep with the main ([]) button, which is instant on and off.
Screen was already calibrated, and the normal start-up wizard ran for Android.
Pre-Installed Software:
Aside from the standard stuff, you get ES File Explorer, Meridian Media Player, Skype (I’ve not tested that yet), SkyFire Browser, Aldiko eReader, QuickOffice, YouTube App and Android Market. The pre-installed Android Market worked fine, and I was downloading new apps in seconds. There are also some Chinese apps which I’ve not tried, but overall, there is everything to on there to get you started off and enough for you to use it directly out of the box.
Aside from some demo pictures and a video, there was also some video which I guess was taken when they tested the unit, it is a good sign that they appear to have taken the time to check the unit works, calibrate it, check things like the camera are functional etc (not sure if this was Pandawill or the manufacturer, but it was within an office so I suspect the former). At 0.3mp, the front facing camera clearly isn’t amazing, but in reasonable lighting it is good enough to see the subject in question quite clearly (one thing though is it is mirrored - guess for skype use (if that works)).
Out Of The Box Impression:
Overall initial impressions are, the screen appears to be pretty good for the money. Colours are slightly more washed out than a more expensive screen, but not overly so. The resistive touch screen does take a firm-ish touch to use, but again, not overly more than other resistive touch screens.
The size and weight of the unit appears to be nicely balanced, it is easy to hold in a single hand (for an adult) while using it with another (or thumb typing and holding either side). The outside bezel is just the right size that, if you need to, you can hold the edge with your thumb without touching the screen etc. The plastic housing, which is rigid and feels solid, makes the unit feel quite good quality. The piano black finish of the back (like a psp) does attract fingerprints however the screen itself doesn’t, which is great.
Although it was never going to be the fastest Android experience, however the unit does seem to keep up with the operating system fairly well, definitely fast enough to be usable.
The unit feels nice and appears to work well, so far excellent value for money.
Next time I shall evaluate the tablet against my requirements and see how it fares...
Topic Two : A Low Cost Tablet
Part Three: Passing the grade? (A-E)
Crunch time! How does the low cost tablet fare when lined up against my expectations and needs?
Meeting My Requirements:
A: Replacing A Portable DVD Player
Viewing photos, videos and listening to music from the pre-installed samples was easy and the units response was reasonable. There was good video playback of the 720p sample (I expect this was encoded to suit the device obviously), and the photo browser did a nice job of displaying and sorting through the photos. Sound was ok, by no means hi-fi standard but enough to listen to over moderate background noise (sound as good as the DVD player - but can’t really say this is hard). This will take a bit more investigation to determine what formats are supported and from where (local storage, microSD, flash stick, HDD, network, internet etc etc). However, even if videos need to specifically encoded as long as they can be played from a mass-storage device (or at a push the SD card), this should meet this requirement fine (did I mention the old DVD player is terrible...).
B: A Doodle Pad
It took no time at all for my offspring to try this, safe to say the unit passes this test with flying colours. One huge improvement is that the Blackstone touch sensitive call buttons etc were not in the way any more. Still to find the perfect app for this:
On Windows Mobile its My Note by MyLostBlog which is a good balance between clear interface and function (I still prefer 2.1 over 2.6).
(Click Image For Larger Version)
On the DS, Art Academy is favourite (although what it has in features, it lacks flexibility). Also Flip Note is worth a mention, I would love to find a similar app on Android.
Art Academy (art software) / Flipnote (animation program)
(Click Images For Larger Versions)
At the moment the star for Android is AutoDesk’s SketchBook Mobile (perhaps a little complex for younger children to fully do everything but easy enough for them to use and enjoy most of the features, excellent for adult use too!). AutoDesk’s app shows the quality that is possible with Android (although at the expense of lag free response on this particular device), I’m still very impressed and the 7 inch screen makes it all the more enjoyable.
C: Simple Web-browser
First off the lack of flash is annoying, but there is at least “some” flash support (I assume flash lite) from the Skyfire Browser, and even the google browser when it came across an embedded YouTube video it directed it to the YouTube app to play.
Browsing is reasonable, the wifi signal is probably below normal, but if you have a good signal, the browsing speed as comparable to my phone (for me the google browser appeared to be faster, but that might have been down to my wifi signal at the time). Here, multi-touch or at least the dual-touch of the later M701 models would be useful, as Pinch-to-zoom would be helpful. At least with the 7 inch screen the need to zoom in and out all the time is reduced (also I’m sure by experimenting with different browsers and settings the perfect balance will be achievable). It will never replace the desktop for web-browsing, but it is fine for quick searches etc.
Google Browser / Skyfire Browser
(Click Images For Larger Versions)
D: Music player
I’ll hold judgement on this until I find a more flexible app, since I had problems navigating around my music and playing it by folder unless it was on the SD card (I was only using some files I had available, I’m sure it is a lot simpler with correctly tagged albums). Once playing the music though, it managed ok (although it did experience issues if you attempted to “multi-task” and load apps etc while music was in the background - although that may have been the app I was using and/or fiddling around with the usb connections). The quality isn’t the best I’ve heard, but it is sufficient. I think overall, with the right app, the unit will perform this task without issue.
E: eReader
Just by trying the pre-installed Aldiko application, it is clear to see that this unit is great for reading. The text was very clear and easy to read with plenty of text visible and even on the smallest font setting (point 10) you can easily read without issue. The g-sensor rotates the screen as required (hopefully there is an option to turn it off - for reading while laying down [Yes, there is a setting for android generally]). The screen is slightly shiny so would suffer in direct sunlight, however it is reasonable for reading in average lighting. I also tested with a pdf, which displayed ok using QuickOffice, but features such as re-flow (available with Adobe’s reader) would definitely help to fit things on the screen.
[Update: Once I've installed Adobe reader, pdf's are very easy to read, although the lack of resuming where you left off means you have to keep track of page numbers yourself (this is no different to the Windows Mobile version).]
CONTINUED BELOW...
Congrats!
Really great post
enotar said:
Congrats!
Really great post
Click to expand...
Click to collapse
Thanks! I should be adding some more later on today.
I'm open for suggestions for topics etc.
Topic Two : A Low Cost Tablet
Part Four: Passing the grade? (Continued...F-J)
Meeting My Requirements (Continued...):
F: Camera & HDMI
As I previously mentioned the camera is not very good, but since it is front facing (it’s located to the right side of the ([]) button) it clearly is not suitable for taking snaps etc. Using google-goggles, the images are just about usable, but it appears the google-goggles app can’t take the pictures directly (you can import pictures which then allows you to take photos using the standard app and open them).
(Click Image For Larger Version)
[Android Logo taken with camera]
I’ve just tested the HDMI (I’ve managed to get a mini-HDMI cable) and after enabling the output via the settings page and restarting, the screen correctly displayed on the TV. Films and games do look good on the TV, although some adjustment to the alignment would be useful. Although you can output in either 1080p and 720p, the resolution is matched to the device 800x480 (although I might be wrong for direct video output), also from first impression, 1080p is lower colour depth than 720p output.
G: USB Host
Ideally the USB connection for host/OTG would be it’s own full size female usb socket (i.e. a normal USB socket) but instead you need to use the USB cable provided which converts the miniUSB to a USB socket. Tested with microSD card reader, flash memory stick (4Gb Kingston), the Blackstone (in mass-storage mode) and even 2.5 HDD which worked even without extra power (I was surprised at this as it is only a generic enclosure with a random laptop drive, however I did not try this with a low battery just in case that did damage). All of which appear under the /scsi/ directory. So far I’ve been unable to find how to “unmount” the drives (you can unmount the sd-card and the internal nand memory via the settings but not the OTG device), so when you disconnect you get “USB Device unexpectedly removed” message.
H: USB Device keyboard support
Using the same OTG cable, plugging in a keyboard was easy and seamless (it just works straight away). In fact, I tested this using a Logitech wireless Keyboard and Mouse and both worked perfectly (aside from the fact the keyboard is about 5 times the size of the tablet). I also tried another USB keyboard, which in the past I've noticed does not work when within DOS on a PC (where the Logitech does), this did not work, but I suspect this is simply the keyboard being slightly unusual. Keeping an eye out for a small and cheap keyboard now.
I: RS232 Support
I attempted this just out of interest but not really knowing what to look for can’t be sure it did anything. I don’t expect this to work without some serious work, but will see what can be achieved if anything. The reason for this is that many low level electronics projects can be controlled/monitored using RS232. In addition to this, I’ve also tried a bluetooth dongle (it has no bluetooth built in), and LAN adaptor, clearly they didn’t magically start working (no doubt the build does not have the correct drivers installed etc), but this is something I will look into.
J: A development platform
At a basic level, I can copy over built APK (android application) files and install them, even the ones which I had issues with on the Blackstone work fine on the device. Developing applications and working directly with the tablet is possible (will look at this in more detail another time), as a development device it is ideal.
The not so good...
Hardware Interfaces:
The single OTG mini usb port is annoying, it would be help to connect more than one device etc and not need to use an adaptor cable.
The mini HDMI, again would be good not to need a special cable for this (at least would have been useful to know ahead of time).
Buttons...no physical home or volume buttons, this does make things difficult sometimes (I believe there are software solutions for this, or options to re-map the keys).
Out-Of-Box mapping is: ([]) is power/screen key, right-side of rocker (with Home Icon) is the menu key, left-side of the rocker (with menu icon) is the back key! Once you get used it, it may be the best layout anyway, will need to experiment.
No Usb charging, from a pure ease of use point of view this would be very helpful, but most tablets don’t support this.
Sticking out of the SDHC card (puts the card at risk of snapping) - later version of this tablet this doesn’t stick out.
Obviously multitouch, bluetooth etc would be nice, but we know that.
The Grey Grey market:
This device “IS” a fake...Real Haipad vs. Fake
I can’t work out though if the unit functions any worse than a real one, all I know is, this one functions better than I was expecting and I’ve not found anything which the originals (if it is a fake) did which this doesn’t (so far).
I've now confirmed this with Pandawill, that the tablet is OEM, not a HaiPad original (at least they 'fessed up to it!). Considering it was sold as part of their own "Fight Against Internet Crime" promotion due to their recent DOS hack attack, it is a little naughty but as you can probably tell by now, I am still very happy with the device, no matter it's origin (but glad it was discounted). Also, the device does function as described by the specs, so other than the manufacturer the rest of the listing is accurate.
The only real issue is that new firmware will be a problem since I can't be sure if it will work or not.
Not all joy and perfection (I’d be mad to expect it):
Most applications appear to work, however, I’ve found that Angry Birds has issues with the surface texture graphics (the text which shows the menus/scores - a pain, but the rest of the game is playable). Apparently later versions such as Rio work fine, this just appears to be a feature of the telechip processor and does this for all HaiPad M701. Since I am not obsessed about Angry Birds (I can stop any-time I want, no really I can...) I can live with it. Also Raging Thunder 2 isn’t playable since I can’t see the menu blocks to select anything, I guess for the same issue.
Most games appear to work fine, such as Air Control, TurboFly 3D (lags sometimes, but not surprisingly since its full-on 3D graphics), Waveblaster (works very nicely, with G-sensor working), Pacific Wings (no g-sensor control). The G-Sensor doesn’t work on some games, but fortunately most have alternative options if that is the case.
It's a mixed bag for games, but fortunately I never intended games to be it's main use and I am quite happy with decent puzzle games etc anyway.
Overall - "A solution for now, but not the future":
The unit runs an ARM11 at 800MHz, with 256RAM, lets face it, it will never do all the graphical gymnastics that the Nvida Tegra 2 processors will perform and doing all but the very basics will probably leave it out-of-breath. Such a device is no laptop or even netbook replacement, but much like the iPod touch, it is a media player with many bonus features (& on a much better budget).
I’m sure as time passes (probably not long either) more and more applications will leave this type of low cost tablet behind, with the pace of processor development at the moment this should really be no surprise at all. But for now, the market is open and the apps are flowing, so I’ll sit back and enjoy them!
Topic Three: Low Level Basics
Part One: Oh ADB Debugger!
One of the first steps in getting properly connected to your devices innards is to ensure you are able to use the ADB (Android Debug Bridge).
The ADB is command-line terminal which allows you to directly control the device and file system of the device (or emulated device) from a PC or MAC.
On the face of it you might wonder why the ADB is of much use, the answer is that it allows a direct route to the entire file system as well as providing debug access directly on target as well as monitor log outputs as programs run. Overall it is similar to ActiveSync for windows mobile. Another reason to have this working is that if your device fails to boot, something messes up your system or say the touch-screen fails, you can use ADB to access everything on the device and also re-flash it. Also you will probably need ADB to root your device (more on that later).
There are a number of guides available for setting up ADB, so I won’t go into detail on them. Personally I followed Google’s own developers guide for setting up the Android SDK (Software Development Kit) since I also intend to write Android software and the ADB is part of that.
However, after a quick search, the following guide appears to cover most of the details.
The UnLocker - How To: SetUp ADB/USB Drivers for Android Devices.
For my device, the ADB driver needed some fiddling around with, since windows would not accept the driver was for my device [Editing the ini file and adding the VID and PID of the hardware didn't help me].
Eventually I found the following (following a tip from SlateDroid): The app PdaNet appears to supply suitable drivers.
I also recommend adding the location of ADB to your system path, so that you can call it from any command-line location.
Once the drivers are installed, check that when the device is connected (and debugging is enabled via settings) that typing “adb devices” from the command-line shows a device).
C:\> adb devices
List of devices attached
0123456789ABCDEF device
Click to expand...
Click to collapse
If you want to write software using Ecilpse you’ll also want to check that it can connect and deploy applications directly to the device for testing.
Within the Ecilpse, under the run menu select “Run Configurations...”, within the Target Tab, the “Deployment Target Selection Mode” must be set to “Manual”.
(Click Image For Larger Version)
This enables the “Android Device Chooser” to prompt when you attempt to run/debug from Ecilpse.
(Click Image For Larger Version)
Build and run your application or a test one and it should now run directly on your device.
There are also a number of GUI apps around which make use of ADB to provide easy ways to manage applications, transfer files etc all without needing to mount and unmount your sd cards to and from the device. At the moment I’ve started using DroidExplorer, even from initial impressions it is clear the features are quite extensive (you could probably write about 20 guides on how to use all of it correctly).
an excellent article overall.
question about the tablets: are most apps up-sized to fit the resolution, or are there a large variety of apps natively designed to run at the bigger resolution?
crevlthe said:
an excellent article overall.
question about the tablets: are most apps up-sized to fit the resolution, or are there a large variety of apps natively designed to run at the bigger resolution?
Click to expand...
Click to collapse
This is an interesting question!
Although my tablet is WVGA which is the same as the blackstone (so I can't test this directly!).
You'd need a much higher resolution device to go beyond the officially supported resolutions, (obviously Android 3.0 supports more).
From what I've read and from doing some app development, apps should scale to fit the screen (if programmed correctly). I've read that some apps don't scale for some tablets, what the root reason is for this, I wouldn't know, since the support is there in the API.
Basically, the android sdk provides various ways to describe the layout of your screens, and they encourage you to use ones which describe them in terms of proportional amounts (for the Linear Layout) or in terms of position of items i.e. to the left of item A (for Relative Layout) etc. The other layouts all work along the same lines, i.e. you don't worry about the size of the screen and calculate each position by hand like you do with windows mobile etc, it is all determined by the API.
You can see the different layouts code here and if you find the ApiDemo APK (I'll post if you like) you can view them. However, you can break all the rules and still use the Absolute Layout, where you return to the good old days of x,y co-ordinates. Even then you can use a values which are relative to the screen size and pixel pitch (see Difference of px, dp, dip and sp in android..) so there really is no reason to hard-code it.
As for graphics, I've not done this yet, but I know this handled if you use "9-patch" png files...they describe them here.
The idea here is that the black pixels around the edge allow the designer to say which bits are fixed size and which bits can be stretched to fit etc. It is a really tidy way to do it I think. Imagine how you'd have to do it otherwise if you created a button image with an icon on which would need to be resized to fit!
Oh, there are also provisions to provide low-res, med-res and high-res versions of the graphical resources, so again everything should scale nicely and look good without the need to scale everything all the time. There shouldn't be any need as such for "large" versions of apps, unless the developer wants to change how the app works by making use of the extra space or if they want ensure the "small" version takes up less space. I'm not sure how it determines which resource to use etc or if they all get installed etc, I've not looked into it.
So as long as the designer of the app has done all this correctly then it "should" scale correctly to whatever resolution. Of course, to claim this is true, they would need to test all resolutions. Fortunately you can manually create high-resolution emulated devices so it can be done but that is not the default.
[Now you mention it though, I shall ensure I test any apps I create at least once in high-resolution, it sounds like a good idea!]
I think this might have been why the retina display didn't make it to the iPad2, it would have required app developers to produce yet more app versions to deal with it and re-do the graphics yet again. Unfortunately I don't know anything about how iOS deals with these things, but you don't get the standard sized app in the middle of the screen or a x2 type option as you do with iPads.
Thanks for posting the question, hopefully it answers it (in theory anyway).
Topic Three: Low Level Basics
Part Two: The Root Of It All
I looked and looked for this information but I couldn't find the clear answers I wanted regarding rooting, so here is the info I was after.
What is ROOT, do I need it?
Rooting your device is not essential, for most the things you do with a tablet you will not need root access. Rooting is the process by which you enable “Root” access to the system’s low level files and hardware, this is achieved by enabling “super user” [Linux term for the highest level access which has higher level permissions to files than a normal user (like an Administrator)] access.
In most cases, apps will access hardware and files through the Android API, but in some cases they may need better control of the hardware than the API allows or access to files which are normally locked.
For this reason these applications require “root” access, typically apps which take screenshots (I assume to allow access to the screen data) and backup programs (I expect to allow access to all your files) are such programs.
Am I Rooted?
One thing I had trouble working out was working out if the device was rooted already or not. The quickest way to find out is to try to use an app which requires root access, if you device isn’t rooted it will tell you.
A good way is to download “Terminal Emulator” from the market (or direct from the author) . Then type: su which stands for Super User! (if your device is correctly rooted the “$” will change to “#” (ideally it will also prompt you for permission to enter superuser mode first - see SuperUser.apk below)).
Other signs you are rooted is to look for the “su” file in /system/bin/ but this will not confirm if the file is set to be executable correctly or in some cases different names are used to make it harder for unwanted apps to locate it.
Can I break/brick my device by ROOTING?
Actually ROOTING the device shouldn’t really cause any problems (since all you are really doing is installing a file which allows you to grant “Superuser” access). However, since ROOTING (by definition) allows entering into “Superuser” mode, this mode does allow you make much more serious changes to the system than you would in a “Normal User” mode (which is the whole point!), so clearly there are some risks involved while in this mode (and you may want to consider how this fits with your warranty). If your device isn’t open, then I suspect the main risk is getting your device into an unlocked state so that you can perform the root process first (since my tablet was not locked in anyway, I don’t know about this aspect).
Once ROOTING is complete, you don’t remain as a “Superuser” but any application is able to use it if they require. For this reason, the Superuser.apk application is typically installed, which detects when a request for “superuser” permissions are made and allows you to accept or reject the request.
The ROOTING process itself is reversible, which you may wish to do if you need to return your device for repairs etc.
How to root?
There are many guides and methods, but I shall take one specific to my tablet (posted by OffWorld on androidtablets.net) and explain each step in detail, since none I found explain what it is you are doing.
First you need to get the latest su and superuser.apk files from here.
Now, connecting the device to your pc, open a command prompt and type:
adb devices
Adb will respond hopefully with your list of devices:
List of devices attached
0123456789ABCDEF device
This confirms your device is attached and adb is able to communicate correctly.
Command 1:
adb shell mount -o remount,rw /dev/block/mtdblock3 /system
This runs adb (the terminal program to your device) and mounts the specified folders with read/write access.
Command 2:
adb push su /system/bin/
This sends the “su” program to the location on the device (note this assumes have the “su” in the same directory as you are running adb from). You can confirm this by navigating to the location on your tablet and see that the file has been transferred.
Command 3:
adb shell chmod 4755 /system/bin/su
This changes the permissions of the “su” file you’ve just transferred [details about chmod].
By using the command: adb shell ls -l /system/bin/su you can see the permissions.
We’ve changed the permissions from -rw-rw-rw- to -rwsr-xr-x, this allows the file to be executed.
Command 4:
adb push Superuser.apk /system/app/
This installs the Superuser.apk package on the device. This is important since this app allows you to control superuser access, rather than just allowing any program to obtain “superuser” rights.
Command 5:
adb shell reboot
Restarts the device.
Following this process, you will have the SuperUser application installed and applications will request Superuser access if they require it.
Note:
You may find for screen capture programs you need to allow permissions automatically or you may only end up with screenshots of the permission screen! Yes that's how I got the above one...
Excellent topic ! i've got the same pad and was wondering if you did find out a good way to completely backup the firmware. I've used Titanium but that's not a complete dump.
JiePieWie said:
Excellent topic ! i've got the same pad and was wondering if you did find out a good way to completely backup the firmware. I've used Titanium but that's not a complete dump.
Click to expand...
Click to collapse
Welcome to Xda!
That was going to be my next topic.
I've just been focusing on my WM development stuff at the moment (new RSSTab in the works), but will return to the tablet after I am done.
I'm not quite sure the best way to back it up yet, I was planning on trying out the ClockMod route, trouble is I'm quite new to it, so a little cautious about doing it before holidays.
I hope to try out some low level interfacing using the usb at some point too, as I've got a development board to play with.
Side Topic: The Future! Quad core and beyond
This time next year, Rodney...
Just saw this, and thought I would share here!
ASUS planning quad-core Tegra 3 tablet
See the two videos which are on the linked page...
Yes that is 2560x1600 resolution, hopefully to go into a 10" retina display.
Simply said, the future of these chips look rather interesting to say the least (no doubt are related to Sony's NGP).
Looking at the video, what we will be able to do with mobile devices will be rather impressive. Combine that with the new touch and perhaps kinect type control technologies as well as improvements with battery capacity/recharge tech, improved clear & colourful screens and things are shaping up nicely.
Boy are we going to have some fun hacking the innards out of them!
It is easy to see that for me, I've made the right choice by not spending lots of money on an impressive and expensive tablet at the moment. Since I'm happy to wait for a better tablet and until then I can have fun playing with my basic one.
Let just hope that the manufactures come up with a decent device, that is able to be hacked and perhaps might even be half decent out-of-the-box.
What is next? Who knows!
It's interesting really since I think that phones are quite close to the point where they have about as much processing power as they need** (perhaps with the exception of ones which include extra connectivity to HDMI/pico projector, keyboards etc). When they are subjected to the confines of a 3.8"/4" screen, you start to hit the limits of usability rather than processing power. Tablets have given the hardware room to stretch it's legs a little and show us what it can do!
**I'm not saying they won't need more in future, but I think perhaps an upgrade won't be as essential or spectacular, as it once was, until they evolve to the next form of course. I suppose the ultimate progression though is the usability of something like a tablet or pc but packaged in the form of a phone or smaller device in some form or another.
The software needs to catch up now though, we need better multi-core programming techniques, far far better privacy protection, and better stability overall. Thankfully hardware gives us the grunt to do this, it just needs to develop and improve to the point where coding can be done at the highest level of abstraction (which allows time to be spent on creative aspects rather than low level code details).
If you want to look even further, the prospect of re-programmable hardware is getting closer. This is where all the single purpose chips (such as video decoders) are replaced/supplemented by ones which can be re-programmed. Not only does this allow for codecs etc to be updated while still keeping the advantage of hardware decoding/coding (i.e. realtime without loading the main processor or drawing lots of power), but some applications could in-theory call in dedicated processing for specific tasks allowing for some amazing performance when performing complex and processor intensive tasks.
Fun times are a-coming!
Bright things are ahead for our fondle blocks, I don't even care too much if they are android or ipad or something else, as long as we can buy it (without selling a leg or two - ok, not iPad then!), program it, play with it and push it to it's limits and beyond!
Side Topic: Multi-Touch Technology - with No Touch Screen!
ZeroTouch 'optical multi-touch force field' makes a touchscreen out of just about anything
I wonder how much this costs to produce, quite a nice solution and ideal as a add-on to current screens. Depending of the cost of each infra-red and LED module it hopefully won't be too much. Imagine getting it fitted to your coffee table at home!
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).