Okay, first post, I apologize if I've broke a rule. And I didn't see this question anywhere. So... Is there any way to use Android 2.0 on the Omnia II? I don't really like Windows Mobile and wish I could replace it. Thanks.
Perhaps in the near future.
Two phones have similar hardware to the Omnia II: first is the Samsung Moment and the next is the Samsung Beam.
The three share the exact same CPU and only the latter differs in RAM; the beam has 384mb ram but this is probably because it also sports a projector and I assume it is going to be a very resource intensive app.
Both the Beam and the Moment (well at least the Sprint version) will eventually have Android 2.1 on there. If someone still has an interest in this old device which seemed to have so much support and potential behind it only 4 months ago they may decide to get the software from that phone and do a few tweaks to have it running on the Omnia II.
There presently is an Android on Omnia dev but the fact is he is going to have a really hard time porting Android on a device which is quite different to anything current on the market now (the Armv6 instruction set is quite dated). Hopefully he moves onto porting instead of building from the ground up like he is doing now, though he may elect not to because he has probably done a lot of work. IF he or someone else ports it will be a very good Android phone, if it is built from the ground up i have a strong feeling it will lag and crap out worse then the Omnia 2 with Samsung BloatWiz on it right now.
=====
In my opinion Modus Windows Mobile is not the issue, it is Samsung. They have a very poorly coded user interface called "Touch-Wiz". All you need to do is go into the My Menu, Find "settings " > click "Display and Light" > click "Items on Today" > scroll down and go to the Samsung widget plus and untick the box > Now go to the very bottom and just tick "Windows Default". Click Done.
You have to wait a second now go back to your home screen, you no longer have three screens (a useless feature anyway) but everything is faster now. You can also make it look better by going back into that place and clicking "themes".
Thanks. I'll give it a try and check the forum periodically for Android-on-Omnia2 news.
I've been working on this for quite a time now. (see modaco can't post links yet)
Okay I've uploaded all the necessary files. But no time to make a manual. So please, only those who know what they are doing try it out. For the devvers: in winmo change usb mode to mass storage (my internal storage), stick in into linux, change the size of the vfat internal sd, add an ext3 partition. Make sure you chmod it. And there you go!
My plan is to setup a dedicated website with the full source, split up in to braches for the different s3c6410 devices and supported drivers. This costs money and time, my plan is to do this next week.
For those of you who showed support by donations, I would like to do something extra for you guys. I apreciate this, Please PM me if you need any help and have considered the above but can't get it to work.
Paypal:
EDIT:now it is working
rapidshare:
--Alpha Release--
Note: to accomplish booting android requires reformatting the internal sd, this might brick your phone, I only recommend it for the more advanced (linux) users. I will take no responsibility for this. This release is soley for a proof of concept purpose. For the non-devvers: you could try to see if it works from vfat, you'll have to use mmcblk0p5, I know it gets to the android screen or make .img from these files and use an initr and mount the images.
What works:
-frame buffer
-s3c6410 cpu
-internal sd
Android is now in a state where you could open up almost anything, watch a slide show But because of the TC you need to press a little below/left on what you want to click due to faulty calibration.
What is in the making:
-ALSA support
What needs to be done
-hardware keys (using haret) (then we can shuw down the phone, because often you have to reformat the partition due to corruption)
-ADB/USB connection (shouldn't be too hard)
-UART/RIL/DPRAM config (to make 3G/PHONE/text work)
The first two will speed up development, that's why they need to be appended first.
Then:
-Touch screen should be better calibrated
-optimizations/speedups (G2d, G3d, armv6, VFP) + memory layout issues should be resolved. Now only 128 mb is used.
-external SD support (the s8000 android devvers are working on this)
-BT (I don't use it so it has no priority for me)
Which devices are supported?
I think theoretically every s3c6410 omnia/jet/acer iteration should work. But I know some devices will require a small patch to change the frame buffer adress. So please report back failures/successes.
EDIT: ofcourse I will still make a manual these days for the non-devvers, first thing i do when i have time.
Click to expand...
Click to collapse
almar2 said:
I've been working on this for quite a time now. (see modaco can't post links yet)
Click to expand...
Click to collapse
Hey there Almar, how is the speed of the device? Has compiling the drivers been an ok task and what do you think of the new phones coming out soon, will they be of any use to you?
What version of Android have you installed and if it is 2.1, would you say it is at least as fast as pre-2.1 android?
Hey,
I am currently working for IBM, and here we are facing an issue that violates our security policies, so we cant port certain programs to our brand new android phone.
The "request" i have is the following:
We're exploring iNotes Ultra-light (web-based mail) which is also supported for Android. However, one of the item we're struggling with is implementing IBM security policy on the device. Unlike Apple iOS which has a mobile configuration utility, Android doesn't appears to have an equivalent to set device password (8 character, alphanumeric, 90 day expiration, wipe after 10 invalid attempts). I welcome input from the community on how we might address this requirement.
Why should anyone start working on it?
It would be simply for the pride. Imagine to develop a tool, that even the IBM development team is struggling with. It is a big achievement for anyone i think.
So task is open for every developer
Thank you guys.
For someone working for IBM your english isn't very good.
What exact constraints do you want to put on the phone? Make sure that the password for unlocking the phone is 8 char, alphanumeric, etc?
I thought Google had done a bit of corporate development for android 2.2 - had you looked at that stuff? I think they talked about it somewhere in Japan.
ivolol said:
For someone working for IBM your english isn't very good.
What exact constraints do you want to put on the phone? Make sure that the password for unlocking the phone is 8 char, alphanumeric, etc?
I thought Google had done a bit of corporate development for android 2.2 - had you looked at that stuff? I think they talked about it somewhere in Japan.
Click to expand...
Click to collapse
Ah, yea my English might not be perfect, but IBM is an international corporation and im working in one of the European countries. Thats why
Also the "request" i did not write. It was copied from one of the insider forums and pasted here.
About the issue i think the problem is with the options (if the basic passwd requirements are configurable [ 8 char, alphanumeric]) to set a maxage and minage, and as well the wiping of the device if the password is entered 10 times incorrectly.
Bump
<too short>
Bump again
I am bumping this thread again, and i noticed there were more people interested in it, than only me. Android is just not good for Enterprise usage. I dont think the problem is a hardware problem, more like a proper softer at boot up, but i am really not into Android programming, especially not to this depth, that is why i turned to this community.
An other thread about the same issue here :
http://forum.xda-developers.com/showthread.php?t=784282
Hi all,
A few weeks ago I started taking apart the LiveView software and manager. I'm really unhappy with the current plugin system, the menu structure and more. So, I started to reverse-engineer the Bluetooth protocol. I'm at the very beginning but it's looking promising.
Here's the repo: https://github.com/BurntBrunch/LivelierView
The protocol is not very difficult - just request-acknowledge-response serial communication over RFCOMM. Also, the kind people from SE didn't run the manager through Proguard (wink, wink, nudge, nudge ).
I also have what I *think* is a dump of the firmware but it seems either compressed or encrypted. Binwalk didn't find anything in it. If someone would be kind enough to take apart the software updater, we might figure out what's running on the actual device as well.
Overall, I'm just starting but so far it's looking good (got time syncing working! it's at least a watch, if nothing else! ).
Any help would be greatly appreciated (pull requests are more than welcome! )
thinking of doing something similar with one of my gadgets.
What did you use to reverse-engineer the Bluetooth protocol, just wireshark and a bluetooth dongle
Neither Did it from disassembly of the manager - much easier than sniffing and guessing.
If you don't have that option and said gadget connects to an Android phone, put on a decent ROM with the full BlueZ stack (e.g., Cyanogen) and use hcidump. It's really, really useful!
Come to think of it, Wireshark might be good enough - the only thing I found useful about hcidump was the SCO audio dump.
Nice effort. I've already forked your work on github, might have a look at it soon, I got some geeky ideas for myself as well, and I think integrating this functionality natively on CyanogenMod or even a custom app to replace the SE's one would be great to have as well.
Nice,
i'm was disapointed by the liveview manager myself, i hope something good emerges from your work
I've also decompiled the APK, and it seems that everything that displays on screen comes from the application, which means everything could be costumized. Seems like SE is using a PNG lib LodePNG to convert images and pushing them to the phone. Also, when it comes to strings, I've found some useful references in JerryProtocol that might indicate how the correct text encoding (not that we can push it right now, but just for the record):
Code:
private static final String mEncoding = "iso-8859-1";
private static final char cCarriageReturn = '\r';
private static final char cLineFeed = '\n';
Controlling the led seems quite simple to, it seems message's data is divided in 3 parts:
[RGB] [DELAY = Integer Number] [ON STATE = 0|1]
[old]although I've not figured out the ID of the LED control yet[/old].
LED request ID is 40 and LED response ID is 41. Hope this is enough for you to get started on that one too
I've not yet tested the app, but I've read your code and gave a shot at decompiling trying to see what I could dig up, will try it later (not very used to running python scripts though, will have to see how to install pyserial first and all that)
pedrodh said:
it seems that everything that displays on screen comes from the application
Click to expand...
Click to collapse
Yup, the main stuff is on the phone - the state machine is clearly isolated (on a side note, the manager is rather well-written, thankfully). On the other hand, I'm somewhat confused by all the constants - it almost feels as if the device has native navigation or icon cache or something.
pedrodh said:
Controlling the led seems quite simple to, it seems message's data is divided in 3 parts:
[RGB] [DELAY = Integer Number] [ON STATE = 0|1]
LED request ID is 40 and LED response ID is 41. Hope this is enough for you to get started on that one too
Click to expand...
Click to collapse
Thanks for the interest and the tip, I'll look into it soon - I need to figure out a good way to send commands from stdin. It seems that I'll need to figure out non-blocking reading in Python anyway (good news for you - I might drop pyserial! )
In any case, I'll add it to protocol.txt, unless you beat me to it!
Lastly, the only reason it's in Python is 'cause I'm productive in it *and* it has good, fast bindings (I try to stay away from gobject in C!). Whatever comes out of this effort would be running on the phone, surely
Edit: You *did* beat me to it!
Edit: Implemented LED, vibration, and a pretty good scheme for sending commands from the CLI
Nice work, saw quite a few commits in a small amount of time.
I've not yet been able to run it sucefully, I (think) have installed pyserial correctly, but maybe the problem is that the bluez that comes with my ubuntu is somewhat newer than the one you used, anyway here's as far as I got http://pastebin.com/uVRdr5T3 if you by chance know just by looking at it what it is would be great .
I've started an Android applicatoin Project in hopes of porting this to an Android application as well, but I'm somewhat new to Bluetooth handling on Android, still working it out. I'm already able to connect and pair with device (noob stuff), but it fails to READ from it. I've used java's DataOutputStream and DataInputStream since they deal with data in a big-endian notation, but I haven't understood yet how the initialization process goes. I've looked to your code, I get some parts but not the whole thing yet. Do you have to wait for the LiveView to tell something back, or you can just start to send commands at random? Also, does the script act as a bluetooth server or client (it seems that they are distinct when coding in Android, I've choosen to Connect as a Client, and yes I used the same UUID that you got from decompiling so at least that part I guess to be correct) ?
Anyway is just a bunch of very ugly code at the moment, after I get it to do something usefull I'll clean up the project and host it on github as well.
Hmm, that error is rather suspicious. Looking at the docs, Connect() is not even supposed to throw org.bluez.Failed, let alone with that message. And service discovery supposedly finished successfully..
Was the device in pairing mode (with the arrows/circle turning)? Was the computer the last thing it paired with (once you pair with the computer, the phone shouldn't be able to connect to it, since the device only remembers the last authorization)?
Install d-feet, the DBus browser, go under System bus, org.bluez, find the device, verify that it has the org.bluez.Serial interface and try calling Connect() with the proper UUID from there. Other than that, I've really no idea what it's on about.. Do you have more than one LiveView device by any chance (weird things might happen then)?
I don't actually think it's the difference in bluez versions (the Serial interface hasn't changed in the past 2 and something years) but it might be a (driver) bug you're hitting. I *think* I'm doing everything right as far as communication with BlueZ is concerned. Try running `hciconfig hci0 reset`.
Sorry I couldn't be more helpful..
Regarding your Java effort, if I recall my Bluetooth terminology correctly, you are a client, since the server is the thing advertising the service. You should *not* be reading immediately from the device. The phone/computer sends the first message - in my case, my first message is always STANDBY. Then and only then can you start reading back.
Lastly, I hope Android abstracts the whole RFCOMM pipe thing, 'cause it's a pain to use (and the reason I still need pyserial) - select() would sporadically tell me it has data to read and when I try to read it, I get ERRIO :/ I suspect RTS triggers select()..
Make sure you're only reading as many bytes as you know are in the next packet (take a look at consume() - it returns the number of bytes it expects next) and not more than that - it would either block or throw an exception. I've not done any Bluetooth work on Android, so that's as much as I can help, I'm afraid.
Lastly, as big as the temptation is, do not under any circumstances reuse code from the official manager. "Sony" is in the name of the company after all. I'm half-expecting a Cease & Desist any moment now
Edit: Implemented Display Properties Request and Clear Display Request (doesn't do anything). I think I'm out of low-hanging fruit
Really interesting work, guys. The Liveview is a fantastic idea and is almost brilliant - if only it worked properly! If you could get the basics working properly so we don't have to use the Sony software that would be fantastic, it's got so much potential.
Cheers,
Tim
So, I had a brilliant idea today. You know how the LiveView Manager app is full of debug messages. Turns out, they are disabled by means of a constant in ElaineUtils. My idea was to change that constant, put the apk back on my phone and rejoice from all the extra info I'd have.
Turns out, that's not how it works. I changed the constant (bumped it to 0x100 - literally a single bit change) and re-signed the apk. I got some output out of it but not all, and none of the useful ELEMENT_ID_* messages
Any help on that front would massively speed up the reverse-engineering effort.
EDIT: Scratch that, I'm stupid. I forgot that the .field annotations are not executable code - I was changing the wrong bit so to speak. Changed the value in <cinit> and voila, proper logcat!
EDIT: Here's some food for thought - http://pastebin.ca/2099804 - it's the log from startup + a bit of moving around and opening/closing the mediaplayer control.
Very cool project.
I believe, for the damn thing to be usable, focusing on improving Bluetooth performance would be quite good. By "performance" I mean "power consumption." Having to give up on the watch after two hours of light use is really unacceptable.
I would love it if you got this thing working efficiently like SmartWatchm/OpenWatch did for my MBW-150. I ordered my LiveView from the UK when it first released there instead of waiting for the US release. The darn thing disappointed the hell out of me and has been sitting in my garage for almost a year now.
Hopefully you get something going on with this.
archivator said:
So, I had a brilliant idea today. You know how the LiveView Manager app is full of debug messages. Turns out, they are disabled by means of a constant in ElaineUtils. My idea was to change that constant, put the apk back on my phone and rejoice from all the extra info I'd have.
Turns out, that's not how it works. I changed the constant (bumped it to 0x100 - literally a single bit change) and re-signed the apk. I got some output out of it but not all, and none of the useful ELEMENT_ID_* messages
Any help on that front would massively speed up the reverse-engineering effort.
EDIT: Scratch that, I'm stupid. I forgot that the .field annotations are not executable code - I was changing the wrong bit so to speak. Changed the value in <cinit> and voila, proper logcat!
EDIT: Here's some food for thought - http://pastebin.ca/2099804 - it's the log from startup + a bit of moving around and opening/closing the mediaplayer control.
Click to expand...
Click to collapse
Wow, that's very useful thank you. I've been very occupied and did not work more with the Android Side application since my last post, I intend to return to it soon enough though, that output is very welcome when it comes to understanding then the icons are sent and the whole mechanism itself.
I've been doing a bit of reverse engineering work on the liveview as well, and I think I have a complete (although i fear possibly slightly corrupt) firmware dump!
I have been able to extract was some PNG images from the firmware (Thanks to their rather distinctive %PNG Header and ending with IEND).
It would appear that the menus and stuff are in fact definitively transferred over bluetooth!
I've attached the images I've extracted if anyone's interested in seeing them!
I'm currently trying to work through it in IDA to disassemble it, which is a pain in the arse!
Is anyone else also interested in completely rewriting the firmware?
@aj256, nice work! I thought I had a dump as well but mine looked compressed :\ Mind uploading yours somewhere for all to see? (edit: sorry, saw it in the archive)
aj256 said:
It would appear that the menus and stuff are in fact definitively transferred over bluetooth!
Click to expand...
Click to collapse
That's correct - I almost have that part of the protocol figured out but I'm low on spare time.
aj256 said:
Is anyone else also interested in completely rewriting the firmware?
Click to expand...
Click to collapse
Well.. I'd be interested in modifying it and isolating the Bluetooth stack but don't really have the time OR the chops to write the whole firmware from datasheets and disassembly.
As for where I'm standing, I know what I need to decompile next (renderShowUi) but it's a couple of thousand lines of smali. There are so many branches, it's easy to get lost. I need to write better tools for decompiling smali first
Just bought a Live View! I know it may not be the best but I got it cheap and mainly want the Caller ID portion of it. I hope this reverse engineering pays off. Once I get mine I may start poking around and see if I can help out! Thanks for the post OP!
Hi,
do you guys have some irc channel or anything else? Just got my LiveView and want to help you with this...
I've quickly put together a project website at openliveview (dot) com (apparently I don't have enough posts for an external link!) with some forums as well to help to document peoples progress!
I've done a quick writeup on my progress so far (which isn't very much!)
@archivator, glad you found the firmware in the zip, I was just about to reply that it was there!
aj256 said:
I've quickly put together a project website at openliveview (dot) com (apparently I don't have enough posts for an external link!) with some forums as well to help to document peoples progress!
I've done a quick writeup on my progress so far (which isn't very much!)
@archivator, glad you found the firmware in the zip, I was just about to reply that it was there!
Click to expand...
Click to collapse
Nice. I've been on your website and the documentation is getting in good shape. When I got some free time I'll try and read it more carefully and complement the Android project.
Talking about that, I've uploaded my progress so far to github: https://github.com/pedronveloso/OpenLiveView
bare in mind that apart from pairing with the Device not much is actually working by now, contributions are welcome of course
My friend wants to see if I can hack his wifi with my phone and I'm pretty sure I can. I can do it on my iPod Touch, but I'm kind of new to Android. Is there a way I can hack WEP and WPA2k?
Willanhanyard said:
My friend wants to see if I can hack his wifi with my phone and I'm pretty sure I can. I can do it on my iPod Touch, but I'm kind of new to Android. Is there a way I can hack WEP and WPA2k?
Click to expand...
Click to collapse
I have been curious about this, too. I imagine you could find some ports of aircrack out there. Otherwise you could shell and run a program like aircrack that would log packets and then transfer them to a more powerful computer to crack them later.
How did you manage to do it on your iPod touch?
I saw a thread like this closed the other day, pretty sure it's against the rules.
Just a heads up.
Naria9 said:
I saw a thread like this closed the other day, pretty sure it's against the rules.
Just a heads up.
Click to expand...
Click to collapse
Well it certainly will be now. Thanks Einstein!
The fastest way most "hackers" get past WPA/WPA2 is to brute force the WPS pin with a tool like reaver-wps, though I'm not sure if it has been ported to android. Don't think it would be hard to port, would just take some work.
As for WEP, things like Aircrack-ng may or may not work based on what your hardware is.
Ji(n)X said:
As for WEP, things like Aircrack-ng may or may not work based on what your hardware is.
Click to expand...
Click to collapse
Highly hardware-dependent indeed. And since Samsung doesn't publish datasheets for the hardware they package in our devices, we don't really know if the wireless interface supports monitoring mode and packet injection (talking for the Galaxy S2 here of course, don't know about other devices -but I seem to recall reading that on the HTC Desire S (my previous piece of s... phone, sorry) it's a no-go, the wifi interface is too basic to include this functionality -unverified though).
Maybe someone who installed Backtrack5 on their device can answer this ?
download Backtrack installer. follow the instruction and boom there u go. I use it on my photon/kindle all the time.
might do this later on, I been toying with the idea lately anyway.
But first in the pipeline is fully trying out the dual-booting possibilities of the Siyah kernel for SGS2.. xD
(can't very much have both at the same time, since from what I gather, on an SGS2 the Backtrack install would populate the hidden and unused mmcblk0p10 partition, which is used for the 2nd OS in a dual-boot..)
Hi All,
I'm a software developer, reasonably comfortable with compiling apps in Linux, though still got more to learn on inner workings of the full system.
I've been thinking about following the Linux from Scratch book for a while - and also about converting my Nook e-reader into a useful device for developing on when out im the sun.
I guess there are some significant challenges here - device trees and commercial secrets, perhaps some crypto keys used for signing update images to boot (I'm familiar with these problems, but not solutions or good workarounds).
What I'd really like is a good understanding of:
- what tool chain I need to setup
- What has been tried already and what the problems were
- any further help/datasheets that can get me going
I'd have posted this in the 'android development' area as the closest forum for what l'm trying to do, but apparently I'm not allowed until I've got my post count up - so I'm being forced to post in 'general'. If someone agrees and can move it, that would be great.
P.s. I have searched the xda site, but I'm not finding what I'm looking for. I'm sure it must be here somewhere, so any pointers/links on where it is would be appreciated.
SimonSimpson said:
Hi All,
I'm a software developer, reasonably comfortable with compiling apps in Linux, though still got more to learn on inner workings of the full system.
I've been thinking about following the Linux from Scratch book for a while - and also about converting my Nook e-reader into a useful device for developing on when out im the sun.
I guess there are some significant challenges here - device trees and commercial secrets, perhaps some crypto keys used for signing update images to boot (I'm familiar with these problems, but not solutions or good workarounds).
What I'd really like is a good understanding of:
- what tool chain I need to setup
- What has been tried already and what the problems were
- any further help/datasheets that can get me going
I'd have posted this in the 'android development' area as the closest forum for what l'm trying to do, but apparently I'm not allowed until I've got my post count up - so I'm being forced to post in 'general'. If someone agrees and can move it, that would be great.
P.s. I have searched the xda site, but I'm not finding what I'm looking for. I'm sure it must be here somewhere, so any pointers/links on where it is would be appreciated.
Click to expand...
Click to collapse
I have tried to get info on such things three times over 2 years for different devices, no one every seems to point me in the right direction, the most i have been able to find out is how to make compile cm and a little bit of how to customize roms, not to be a downer but i think the process is often so different for ever device and difficulties usually happen that the only people that build roms are people that have either have experience I n some form from their job, just edit existing source for cm(updating to a new version, customizing roms ect...) or have screwed with the stuff for years till the point that they just figured out alot of problems themselves. Wish a could find a good guide myself to atleast get the basic dependencies required for a device to boot together, if i could get something to boot the rest of the issues could be worked out with trial and error, boot noone on xda, Android authority, Reddit or cm's own forums goes into enough depth to make that possible.
Hi jaykoerner,
Thanks for your reply - good to know I'm not alone with my echo!
I've discovered some useful links if anyone wants to begin getting to grips with all this...
1. XDA Devs has a wiki (not sure how to find from the forum links...?)
http://forum.xda-developers.com/wiki/BN_Nook_Simple_Touch
2. There's a (atleast one) customized kernel (and probably a dev-tool chain) available on GitHub:
https://github.com/javifo/NST/tree/master/kernel -- including kernel compilation instructions
https://github.com/javifo/NST -- root of the repository.
3. Parallel to Raspberry Pi kernel compilation (so you may want to learn from that as it probably has more articles)
https://www.raspberrypi.org/documentation/linux/kernel/building.md
I'll post more when I next do something with the information (Still want to understand more on the android HAL)
Hope that helps someone!
SS.
SimonSimpson said:
Hi jaykoerner,
Thanks for your reply - good to know I'm not alone with my echo!
I've discovered some useful links if anyone wants to begin getting to grips with all this...
1. XDA Devs has a wiki (not sure how to find from the forum links...?)
http://forum.xda-developers.com/wiki/BN_Nook_Simple_Touch
2. There's a (atleast one) customized kernel (and probably a dev-tool chain) available on GitHub:
https://github.com/javifo/NST/tree/master/kernel -- including kernel compilation instructions
https://github.com/javifo/NST -- root of the repository.
3. Parallel to Raspberry Pi kernel compilation (so you may want to learn from that as it probably has more articles)
https://www.raspberrypi.org/documentation/linux/kernel/building.md
I'll post more when I next do something with the information (Still want to understand more on the android HAL)
Hope that helps someone!
SS.
Click to expand...
Click to collapse
My initial thought was that toolchain should match the underlay Linux kernel of Eclair (2.6.x.y) for us to be sure it could be run on NST. This info that I still have to search through is certainly helpful. Thanks!
SimonSimpson said:
I guess there are some significant challenges here - device trees and commercial secrets, perhaps some crypto keys used for signing update images to boot...
Click to expand...
Click to collapse
Neither the NST or the newer glows use device trees.
In the Glows this is all handled by the custom ntxconfig which allows simple configuration.
For building Android apps, you use the straight Android SDK, possibly also the Android NDK (for native code).
You'd also use the NDK for building command line utilities.
I've never built a kernel from scratch, but I have binary modified/patched them.
There is the simpler bit of patching system image ramdisks which can be conviently handled by my imgutil.exe in the signature.
If you want to do audio, you really are better off with the Glow4 (7.8") which actually supports it.