Database Users

Calling HTC Linux Geeks + Android Fans: MSM7200 Compatible Kernel Released!

Ok, there is plenty of speculation on Android and can we run it on our HTC devices, etc. I have started this new thread dedicated to the MSM7K Kernel release, and what it will take to get this running on our phones.
I would like this thread to become a resource, rather than just general theorizing. For example: "I know we need driver X to run Y on HTC device Foo." What I am not looking for: "Android is so l33t, plez tell me how to run on my Zaurus kthx". The difference is that the first example is constructive, and adds to the discussion.
The signal to noise ratio on the Android gGroup is terrible, and mostly consists of wild theorizing, self-promotion, and arguing. I have a feeling it will improve, but for now I'd like to discuss this subject away from all the SuperKoolNewAndroidForum.com forums.
My Goals for this Thread:
Establish what is known to work, and what the kernel is sorely lacking.
a) I know we have booted Linux on HTC devices, has it been done on the most current devices? (please link to thread/proof)
b) What are the main major roadblocks preventing Linux from being run on more HTC devices? (Obscure hardware design, bricking phone)
Compile a list of needed and helpful software for loading Android: bootloaders, useful Linux tools, filesystem images
Provide continual updates with photos/logs as we (hopefully) make progress
My bet is that the current 'gPhone' in the videos is an HTC device not unlike yours or mine. [link to my blog] IMHO, the hype over 'When will the first gPhone be released' is irrelevant, as Google has been working closely with HTC and Qualcomm for a long time -- and the specs for Android are so low, Google clearly expects to be able to run Android on existing hardware, without needing new hardware technology.
Of course, the tools and software we need are all in existence already, someone at Google is doing a good job of keeping their mouth shut. Therefore this is not an impossible task, just difficult, but I know you xda-hackers like a challenge! So, Let's go!!
Charles
FYI: I am aware XDA was founded with the Xanadux project, so this should be the perfect place to hack us a gPhone. I've also browsed threads, read the Wiki, studied up on the Hermes Linux project -- but things seem to have died since Feb 07, I'm hoping this latest development with Android will spark interest again, and we will be able to run Linux on our current, most powerful devices. I could make educated guesses about the state of the Xanadux project, but I'd rather hear it from XDA devs themselves who are most familiar.

Reserved for knowledge & files
Ok, I'll start:
Android.com *Now redirects (finally) to OpenHandsetAlliance.com
Download Android SDK
Official Android Dev gGroup
Here's what I know:
Announcement of the Kernel on the ARM Linux Mailing List
GIT Repository
gGroup for MSM7K Kernel Issues
[credit to Brian Swetland, Linux Kernel Lead, Android Project]
gGroups thread: Compiling C Binaries for Android
Filesystem dump from Android running on SDK Emulator: gGroups thread discussion | Benno's blog post with files

reserved for Android installation instructions
[ reserved ] Hopefully we will get this far

polyrhythmic said:
I've also browsed threads, read the Wiki, studied up on the Hermes Linux project -- but things seem to have died since Feb 07
Click to expand...
Click to collapse
If you are interested in the facts, and not some google-related hype, please
check this one
http://www.handhelds.org/moin/moin.cgi/UniversalStatus

My Android News blog (now on Russian language)
English version cooming soon.
http://android.my1.ru
Now it is under construction

Much thanks cr2!
n00bs are everywhere I'm trying not to be one of them.
I have been doing a lot of reading, things have been quiet on the Kaiser front but that soon will change. I just read the #htc-linux logs from the past few days, see you there after work!
Charles
(sent from das Kaiser)

WoW!
Is this going to be like getting Linux OS on my Trinity? I like the browser but a lot of the apps in teh demo vid rely too much on 3G. Data rates in the UK are prohibitive at the moment so I stick with WIFI

welcome to join AndroidPort group
hello:
you are welcome to join the AndroidPort group, where the
idea is to make Linux and Android work on a real or virtual
hardware phone platform.
looks like you are quite advanced in this area. we would
welcome your presence and expert knowledge.
have a look at our website. you will find a lot of
information for this subject in 1 place.
AndroidPort
http://groups.google.com/group/androidport
Aaron

Cool initiative, will write about it in my next News collection.

polyrhythmic said:
Ok, there is plenty of speculation on Android and can we run it on our HTC devices, etc. I have started this new thread dedicated to the MSM7K Kernel release, and what it will take to get this running on our phones.
I would like this thread to become a resource, rather than just general theorizing. For example: "I know we need driver X to run Y on HTC device Foo." What I am not looking for: "Android is so l33t, plez tell me how to run on my Zaurus kthx". The difference is that the first example is constructive, and adds to the discussion.
The signal to noise ratio on the Android gGroup is terrible, and mostly consists of wild theorizing, self-promotion, and arguing. I have a feeling it will improve, but for now I'd like to discuss this subject away from all the SuperKoolNewAndroidForum.com forums.
My Goals for this Thread:
Establish what is known to work, and what the kernel is sorely lacking.
a) I know we have booted Linux on HTC devices, has it been done on the most current devices? (please link to thread/proof)
b) What are the main major roadblocks preventing Linux from being run on more HTC devices? (Obscure hardware design, bricking phone)
Compile a list of needed and helpful software for loading Android: bootloaders, useful Linux tools, filesystem images
Provide continual updates with photos/logs as we (hopefully) make progress
My bet is that the current 'gPhone' in the videos is an HTC device not unlike yours or mine. [link to my blog] IMHO, the hype over 'When will the first gPhone be released' is irrelevant, as Google has been working closely with HTC and Qualcomm for a long time -- and the specs for Android are so low, Google clearly expects to be able to run Android on existing hardware, without needing new hardware technology.
Of course, the tools and software we need are all in existence already, someone at Google is doing a good job of keeping their mouth shut. Therefore this is not an impossible task, just difficult, but I know you xda-hackers like a challenge! So, Let's go!!
Charles
FYI: I am aware XDA was founded with the Xanadux project, so this should be the perfect place to hack us a gPhone. I've also browsed threads, read the Wiki, studied up on the Hermes Linux project -- but things seem to have died since Feb 07, I'm hoping this latest development with Android will spark interest again, and we will be able to run Linux on our current, most powerful devices. I could make educated guesses about the state of the Xanadux project, but I'd rather hear it from XDA devs themselves who are most familiar.
Click to expand...
Click to collapse
where is the video?

anheuer said:
where is the video?
Click to expand...
Click to collapse
YouTube Your best friend , along with google obviously

Support Cyanogen and the cause, read further

(Note posting in this topic as to dev category for obvious reasons)
This whole incident has taken me by surprise with the actions of Google against Cyanogen. Now the actions from my understanding so far are likely the result of the early release of the Market app with his new Donut based releases. There is a valid argument for Google in which it is their own proprietary code in which they want to release on their terms I would assume, however I prefer to take the side of the community. The community around XDA has supported and nurtured the development of the Android OS and the devices based upon it, with the developers pushing the limits on what they can do and implementing smarter and better solutions. We the community in a sense become beta testers for the latest and greatest Android has to offer, how many applications do you think have already added support for 1.6 due to Cyanogen's mods and our feedback?
In summary, I believe while Google does have a valid argument against, but it would better serve them to not continue with this course of action. I invite you all to write and use all social networks available to you to spread the world, submit to every news site, raise awareness of the problem. Don't waste your time with petitions, just spread the word, go viral with it.
Digg search for cyanogen:
http://digg.com/search?s=cyanogen
Original article:
http://androidandme.com/2009/09/hacks/cyanogenmod-in-trouble/
Facebook group:
http://www.facebook.com/group.php?gid=144634407186&ref=nf
Send tweets to @google also, flood the information stream.
Email the people at Engadget, Slashdot, Gizmodo, all the major blogs just to keep focus upon it.

Someone should put it up on reddit too, get some visibility on wired.com!

Listen, this situation is really cut and dry. Cyanogen had NO LICENSE to distribute the CLOSED SOURCE APPS. The rest of it is perfectly fine.
The solution:
Develop the roms, DELETE the closed source apps, sign, publish. When someone installs the roms, let them install the closed source apps themselves -- i.e., *somebody* (who won't be linked back to cyanogen) will likely post a simple "closed-source-google-apps-for-cyanogenmod-4.xx.xx.xx.zip" which can be installed from recovery mode.
Problem solved.

wont that person then be "under-fire"?

gospeed.racer said:
wont that person then be "under-fire"?
Click to expand...
Click to collapse
Only if the person gets caught.

tool to extract non free files and create a update image
If the binary files in a existing ROM can be used by cyanogenMod, what we need is a tool to reuse them in cyanogenMod. Am I wrong?
Or is it rebuild from source code ?

lbcoder said:
Listen, this situation is really cut and dry. Cyanogen had NO LICENSE to distribute the CLOSED SOURCE APPS. The rest of it is perfectly fine.
The solution:
Develop the roms, DELETE the closed source apps, sign, publish. When someone installs the roms, let them install the closed source apps themselves -- i.e., *somebody* (who won't be linked back to cyanogen) will likely post a simple "closed-source-google-apps-for-cyanogenmod-4.xx.xx.xx.zip" which can be installed from recovery mode.
Problem solved.
Click to expand...
Click to collapse
Are you a lawyer? no. So don't give your interpretation of what Cyanogen's license was and wasn't. You already started a thread about it and you're spamming the hell out of another. Don't mess with legal guesses, it's a bad bad idea. As I am someone who is studying law (and also a programmer/generally tech-smart), I am doing and suggesting to stay the hell away from that part when possible. Law -> politics -> flamewars -> ad hominem/bad posts. This is not tvtropes.
Meanwhile, can you even get past the start/initialization page without having the closed source apps, as they are market/gmail? This question is to actual modders.
Google has made a mess of thus, if they stop him from distributing with the apps it's only going to get *waaaay* messier.

You, are an IDIOT.
What happens when you *assume*? I'm sure that if you are, in fact, a law student (as you imply yourself to be, though you really only call yourself a "student" of the law, which could mean that you simply watch CNN from time to time), that this would have been answered on the first day of your first class.
Cyanogen's license *IS EXACTLY* the same as the license granted to *ALL OTHER USERS*. You want to read it? Its in your phone under About Phone --> Legal Information --> Google legal. Until you have read and understand *it all*, you should immediately cease offering your suggestions.
Edit: I just noticed your post count... 3.
Amazing, the audacity of some people. Whenever things start to get beyond the understanding of the average, all the chicken-littles come out from the woodwork and start crying about how evil the big company is. It is a direct function of a lack of understanding of the issues.
My advise: FORGET ABOUT IT. This has nothing to do with you and most likely won't have any (significant) impact on your life. At worst, you will have to add ONE SMALL STEP to the process of flashing the latest modrom.
Let me repeat: THIS IS NOT A BIG DEAL! IT DOESN'T REALLY MATTER! Your phone is NOT about to catch on fire or start spying on you.
Oh, and for you information: regarding how I know what Cyanogen's license was....
1) the fact that it is included with the phone.
2) the fact that he received a c&d order (which they wouldn't send if he was licensed, or if they had, it would be the simplest matter to resolve).
3) the fact that he said so himself.
designerfx said:
Are you a lawyer? no. So don't give your interpretation of what Cyanogen's license was and wasn't. You already started a thread about it and you're spamming the hell out of another. Don't mess with legal guesses, it's a bad bad idea. As I am someone who is studying law (and also a programmer/generally tech-smart), I am doing and suggesting to stay the hell away from that part when possible. Law -> politics -> flamewars -> ad hominem/bad posts. This is not tvtropes.
Meanwhile, can you even get past the start/initialization page without having the closed source apps, as they are market/gmail? This question is to actual modders.
Google has made a mess of thus, if they stop him from distributing with the apps it's only going to get *waaaay* messier.
Click to expand...
Click to collapse

gospeed.racer said:
wont that person then be "under-fire"?
Click to expand...
Click to collapse
At this point we're talking warez, and though I won't advocate warez, when was the last time you saw Ahmed Ahmed Ahmed from Iran get persecuted for distributing warez?
Remember that the US government can't even find Bin Laden....
Or the apps can be pulled by the users from *legitimate* images, like ADP1. This, at least, is legal for owners of ADP1's for use on ADP1's.
Frankly, adding a step to complicate the process would probably go at least a little way in getting the super-noobs out of the game. They get *really* annoying.
Oh FYI: I got that board you sent me more-or-less cleaned up now, going to start mapping it out soon.

setupr said:
If the binary files in a existing ROM can be used by cyanogenMod, what we need is a tool to reuse them in cyanogenMod. Am I wrong?
Or is it rebuild from source code ?
Click to expand...
Click to collapse
Exactly. It is incredibly simple.
unzip (official-update.zip) /path/to/file1toextract /path/to/file2toextract ... /path/to/filentoextract
zip -g (mod-rom-update.zip) /path/to/file1extract /path/to/file2extract ... /path/to/filenextract
java -jar testsign.jar (mod-rom-update.zip)
Then just copy file to /sdcard/, recovery, flash, done.

Yeah, I know that us modders will continue to be doing the same thing and continue on, I know they aren't going after the entire community. It was for distributing the new Market app before its release as I understand currently. Hell, all I would do I an adb pull from a rom and push it into a new release. Just like I will be doing with the Market app if he can't put it in another release haha.
However the point of this thread was not to see if Google had the right to do that, they did. It is that simple. It is their proprietary code that was released early, by cyanogen, but I think it is unnecessary. The point of it was to support cyanogen for more ideological reasons, this community pushes the development at a rapid pace. My Dream would have been a nightmare without the likes of JF, haykuro, cyanogen, Dude, etc. With cyanogen releasing Donut in his builds, our community has been pushing developers to up their support to it and fix bugs relating to 1.6 before it is pushed as an update. The same thing with the Market app applies, how many of those apps have screenshots already? Why alienate the true heart of the device, we are basically beta testers for those of us running experimental roms. I understand the Google position, I just wish they would see that no harm, no foul.
And don't equate the amount someone posts to the boards to their understanding of a situation. There are quite a few people that just get the ROMs, run them and can use a search button if they have problems.

holy cow batman, flame much? Some people lurk for a long time before registering such as I.
I agree it's a small issue, and cyanogen is probably already working on it at least based off of his twitter. However, it doesn't matter what you or I feels about the licensing, nor even what the courts would interpret were it to get to that point.
It however, is very inappropriate to be ad hominem and/or bar threatening to people over this issue, basically getting worked up yourself. Honestly, playing seniority and insulting my schooling? I was not trying to be threatning to you, simply pointing out that you are not a spokesperson for interpreting a software license. Really, it's like you went into an emotional rage the minute cyanogen got the C&D.

Cyanogen in trouble
I can't believe Google is pulling this crap. I can only hope that Google is smart enough to work something out with Cyanogen so he may continue to share his awesome developments. I would expect some restrictions, but they need to work with him and let him do his thing. Otherwise, where's the incentive for anyone else following in his footsteps to make programs better for Google?

setupr said:
If the binary files in a existing ROM can be used by cyanogenMod, what we need is a tool to reuse them in cyanogenMod. Am I wrong?
Or is it rebuild from source code ?
Click to expand...
Click to collapse
Maybe this is the answer?
cyanogen : And regarding the keep-proprietary-apps-on-device-for-custom-rom install, with all the odexing and resource id mismatches... Ugh.​http://twitter.com/cyanogen/status/4384352484

Atrix Re-Birth Project

This page is dedicated to make a stable ICS-JB for the Motorola Atrix
Brief history about the project:
- Un unstable ICS for Motorola Atrix was leaked
- Developers worked on integrating kernel and drivers into existing build
- Kernel was found to be very unstable and new kernel is being ported to Atrix
- While we wait for the kernel, an ICS CM9 build is ready for anyone willing to join the challenge
Next step:
- Developers should get involved in fixing/enhancing the current build
- Code submission is done by forwarding the changes to the head development team for inclusion
Build source code is all available to anyone willing to participate. The build process follows CyanogenMOD builds.
Source Code location: https://github.com/MROM/android/tree/ics
Curent Team:
Project Managers: marcovrv and R3PL1C/\NT.
Head Developers: Epinter, MMontuori, and TPoint75.
Kernel developers: mvniekerk
Developers: Hayander, scanuto, ravilov, geleiahp, alberto88a, tachospeedo, Isaygarcia, digidrops, fanfantasy, hainguyen273, and caster62003.
Testers/Advanced Users: Carcara, EkzoMan, EMG92, Hayander, BusWah, Girafik, clockworkninja, rspaulo, Bravo9000, vigremrajesh, jlm-familiar, The-Milkybar-Kid, r3xx3r, ovitz, lightlord, ticiano_arraes, reix2x, Nargyle, diegofdg, shabeepk, pixut, Kaworu33, jhonnyx, Haxornator, fanhtc2, julian_fern, iximedaixi, heibailife, shadowed87, Matada02, Zeljko1234, tatperson, dibi91, NemeZZiZZ, Moonshield, bimasakti85, Cocolopes, Pont91, jeanpiere, pre4speed, jeffreygtab, nachobkcc, BravoMotorola and littleemp.
Without help, this project cannot continue.

Count me in for Rebirth
mmontuori said:
Dear fellow Atrix owners,
We all know by now that Motorola has cancelled the plans for upgrading to ICS, I was hoping myself to get the new drivers to update my own rom to ICS or JB. Well, this is not going to happen...
What do we do now?
We can either assume this is the death of this revolutionary device, or work on the Re-Birth. You probably know, but there are a group of developers working on upgrading the current Gingerbread version to ICS or JB. I am personally one of them...
We all need your help... we are donating our precious time and resources to make the Atrix 4G a better device that could last for another year or two, however, alone, we cannot continue with this...
WE NEED YOUR HELP...
If you are still reading this message, good, now it's time to decide if the Atrix is going to die in the couple of months or live for some time. We are looking for:
- People that can write code and troubleshoot (Android Java and C/C++)
- Testers
- Project managers (believe it ICS or JB is a full SDLC project)
- Android Advanced users not too scared of trying something new on their phones
- Donate Atrix Devices that you no longer need
- Of course, donations to at least justify the amount if time we spend on this
- If I forgot something, please reply to this thread with suggections
Again, you decide DEATH or RE-BIRTH
Take Care
Click to expand...
Click to collapse
It is certainly great to see commitment of this kind. I'm no DEV nor do i possess programming skills which could assist you. But please feel free to count me in as a tester and advanced user, more than willing to get his feet wet .

I will glady donate, as should others who wish to revive this device that surely isnt really outdated

I would love to be a tester and advanced user. I have 2 atrixes, so I can test to any extent on one of them. I would donate one but I need to have my main atrix as a backup to the s2 I am in the process of buying. So my backup backup is there for testing anything and everything needed.

I would have no problem in donating except I don't see anyone claiming that it is at all realistically possible to get the full ICS experience in our phones (meaning hardware acceleration and working camcorder). If that changes, I'd be happy to donate to keep my phone alive, but if it's just going to be another dissapointing waiting game with no outcome...
PS: Don't get me wrong, I'm not trying to rain on your parade or be an ungrateful bastard as I do really appreciate the work all of you devs put on this. I'd be happy to give money for a bounty.

i'd personally donate 50 dollars to the cause of keeping our phones alive. probably more as time went on as well, just to keep the project alive.
i would also be willing to test ANYTHING on my Atrix, as i have plans of replacing it soon anyways. the fingerprint scanner doesn't work anymore, and the touchscreen is dying.

I'm JUST NOW getting an Atrix and a Lapdock, a little late I know But count me as an advanced user willing to test anything. I hope to get webtop (In non-blur roms) working above all else, unfortunately since moto isn't willing to comply, that is also the most difficult task.

- Android Advanced users not too scared of trying something new on their phones
Click to expand...
Click to collapse
Count on me!

Love the intiative :fingers-crossed: I don't have any technical skills to share, but I'm willing to test and assist in any other way that I can.
Maybe we should get this posted on the Photon forums as well to consolidate the project?

Would you be able to develop a 3.x kernel?
Sent from my MB860 using xda premium

Tester and advance user!...
from the (m)ATRIX...

mmontuori said:
Dear fellow Atrix owners,
- People that can write code and troubleshoot (Android Java and C/C++)
Click to expand...
Click to collapse
One more developer ready here !

So you want to build a real ICS/JB ROM for Atrix?
Including a 3.x kernel, hardware acceleration and maybe working webtop?
If at least the first two things apply I would gladly donate for this one.:good:

nachobkcc said:
Count on me!
Click to expand...
Click to collapse
+1 :good:

You guys can count on me as a tester and advanced user!
Sent from my beloved Atrix

Android/Java developer over here. (Also some knowledge in C/C++)
Contact me via : [email protected]
---------- Post added at 01:07 AM ---------- Previous post was at 01:07 AM ----------
Android/Java developer over here. (Also some knowledge in C/C++)
Contact me via : [email protected]
If there is something i can do that doesn't take me a very lot of time (because of the for-a-life work)

This is possible but requires more than a couple of devs working close together to make it come true. And ofcourse, it will spend us certain time for fix the problem of Nvidia named Tegra2 by re-developing a brandnew driver for our device.
Once this mission completed, we can completely go further ahead to open up other attractive projects on this worth device

Definitely advanced user and tester. Have strong experience on tech related project management, just not on software development projects. Novice on java, almost intermediate on C, advanced in Pascal (dead language I know), but I think I'm a quick learner.
Have a "real" job, so time is limited but can arrange something. Just tell me where I can help.
m.rodriguez<at>computer.org
Sent from my MB860 using xda app-developers app

I am honored to be a member of this community!
Not a dev or a programmer here, but will do anything I can to give support.
Thank you all!
Sent from my MB860 using xda premium

I have some experience in Java, C/C++, the Android Framework and I am willing to learn more. But I also think, a project management is necessary to order issues, make possibilities clear, have a big picture, sharing knowledge. So, when you start, drop a message.

Kernel teacher...

Hey everyone, I'm looking for a developer who will be willing to help and teach me how to make a kernel! I would like to be able to add anything I want; meaning I'm looking for someone to teacher how to edit and add things to make it my own, not just teach me how to compile. I've never made anything deal with a source code, meaning I've never made an AOSP ROM nor kernel; I have made some touchwiz based ROMs, but that's a bit different. I would like to start by making something for the nexus 7 (WiFi only) then moving my way to the GsIII (d2spr). I'm currently using opensuse 12.3 KDE 64-bit, on its own HDD. Please, if anyone could help me and teach me, it would be greatly greatly appreciated!!!

What hourly rate are you willing to pay? LOL
What I would recommend you do is to start simply by:
a) installing the current NDK
b) downloading a complete stock kernel build tree as a tarball (.tgz)
c) setting up a build environment and successfully build the kernel
d) unpack an existing boot image, stuff your kernel in there, & re-pack it
e) boot it on your device. Does it run? Congrats! You are a kernel-builder!
The reason that I suggest this outline plan above is that it initially avoids learning git & associated tools until after seeing something you've built running on the device; that's a confidence-booster. That's the good news.
The bad news is that becoming a *good* kernel dev from scratch means that you simultaneously are learning kernel coding conventions, build tree structuring, and kernel APIs *plus* achieving an excellent understanding of how git & gerrit work.
In addition to some amount of original source code mods authored by a kernel dev, they spend a fair amount of time integrating patch sets (commits) coming from unrelated kernel projects (e.g. Linux kernel mainline or kernel mods from unrelated devices). Learning simple operations (commits) in git is easy enough, but understanding branch creation & multi-way merge strategies in the face of cherry-picks coming from arbitrary places is a bit of a mind bender the first time through it.
And there is the issue of compliance with the GPL. As soon as you decide to make public your work, you have an obligation to publish your sources.
There is at least one way to do this simply: don't worry about git/gerrit/github at all - use whatever source code control system you want, including none at all. When you are ready to publish, you publish a patch kit that transforms a specific commit on some other developer's (or google!) tree to your tree. That should satisfy the GPL.
Another thing to consider is to build these skills in an incremental fashion: if you have in mind a very specific kernel modification of original authorship as a first project, why not consider submitting your kernel patches as pull requests to an existing developer's kernel tree? If your patch/mod rocks, other devs will incorporate it - and probably be much more willing to answer twisty questions from you. You scratch their back, they scratch yours.
The point of the above two strategies is that they allow you to build skills incrementally rather than needing to know everything before you can begin doing anything. Don't try to learn it all simultaneously.
cheers

bftb0 said:
What hourly rate are you willing to pay? LOL
What I would recommend you do is to start simply by:
a) installing the current NDK
b) downloading a complete stock kernel build tree as a tarball (.tgz)
c) setting up a build environment and successfully build the kernel
d) unpack an existing boot image, stuff your kernel in there, & re-pack it
e) boot it on your device. Does it run? Congrats! You are a kernel-builder!
The reason that I suggest this outline plan above is that it initially avoids learning git & associated tools until after seeing something you've built running on the device; that's a confidence-booster. That's the good news.
The bad news is that becoming a *good* kernel dev from scratch means that you simultaneously are learning kernel coding conventions, build tree structuring, and kernel APIs *plus* achieving an excellent understanding of how git & gerrit work.
In addition to some amount of original source code mods authored by a kernel dev, they spend a fair amount of time integrating patch sets (commits) coming from unrelated kernel projects (e.g. Linux kernel mainline or kernel mods from unrelated devices). Learning simple operations (commits) in git is easy enough, but understanding branch creation & multi-way merge strategies in the face of cherry-picks coming from arbitrary places is a bit of a mind bender the first time through it.
And there is the issue of compliance with the GPL. As soon as you decide to make public your work, you have an obligation to publish your sources.
There is at least one way to do this simply: don't worry about git/gerrit/github at all - use whatever source code control system you want, including none at all. When you are ready to publish, you publish a patch kit that transforms a specific commit on some other developer's (or google!) tree to your tree. That should satisfy the GPL.
Another thing to consider is to build these skills in an incremental fashion: if you have in mind a very specific kernel modification of original authorship as a first project, why not consider submitting your kernel patches as pull requests to an existing developer's kernel tree? If your patch/mod rocks, other devs will incorporate it - and probably be much more willing to answer twisty questions from you. You scratch their back, they scratch yours.
The point of the above two strategies is that they allow you to build skills incrementally rather than needing to know everything before you can begin doing anything. Don't try to learn it all simultaneously.
cheers
Click to expand...
Click to collapse
Wow, okay, thank you! I'll start with that. Honestly I like having someone just point me in the directions then me teach myself the rest! That is probably the best thing to do all around. I just have somethings:
1.) If I get lost somewhere and am not able to find answer for something anywhere; do you mind if I PM you?
2.) Almost everywhere I read---including from source.android.com---it say, use Ubuntu; why? Do I have to? Ubuntu doesn't support my graphics card---and isn't easy to set up, even when using things from other OSes or just other stuff someone made---which is kinda needed because of my monitors.

jamcar said:
2.) Almost everywhere I read---including from source.android.com---it say, use Ubuntu; why? Do I have to? Ubuntu doesn't support my graphics card---and isn't easy to set up, even when using things from other OSes or just other stuff someone made---which is kinda needed because of my monitors.
Click to expand...
Click to collapse
I've used Unix/Linux for quite a long time, and if there is one thing that seems to never change is package dependency differences from distro to distro. Getting them resolved is mandatory (when you are stopped out by them), but typically quite a distraction from whatever it is you are trying to accomplish.
By using Ubuntu you will be following the footsteps of many others in front of you (including Google developers), and that means that when you encounter a problem, it will be very likely that exact problem has already been encountered and resolved, and you can find the solutions on the internet. That may not be the case for some other arbitrary distro. So, why make your life more difficult?
As far as kernel development goes, you can do anything you want inside a VM, assuming your machine has enough ram (say 4+ GB) and disk space (say 100G free). So get VirtualBox and create an Ubuntu VM.
There are small downsides to using a VM, but for code-building they are just fine - their performance in doing kernel builds is probably 95% of native metal.
jamcar said:
1.) If I get lost somewhere and am not able to find answer for something anywhere; do you mind if I PM you?
Click to expand...
Click to collapse
I would never commit to something open-ended like that - esp. since you said you have never coded anything before. You are free to PM me though, so long as you understand that I am free to choose not to reply. Given those ground rules, it might be better for you to just post your questions in public (say stackoverflow.com) so more eyeballs will see what you are asking.
cheers and good luck - you've chosen a pretty steep mountain to climb.

[Q] Some essential documentation badly needed

I read @Entropy512 write somewhere "we are more in need of developers than of testers at the moment"
To that effect I want to make an appeal to @maxwen @XpLoDWilD @Entropy512 @pulser_g2 and all other people who started the initiative to properly document out a few things
1. If a device maintainer wants to get his device added to omni ROM what should the steps be ?
2. To set up a omni ROM - compliant device tree what are the prerequisites. As in omniROM trees have been seen to be using a format of aosp.mk+custom.mk device makefiles where aosp.mk makes it AOSP-compliant and custom.mk is the omni additions. How custom.mk is to be made (a template maybe ?) should be be documented. In fact I would go out to say a device/custom/sample tree should be made as an example
3. Are there any guidelines as to how much the hardware side codes can be hacked with to make the devices supported ? (Many groups of developers have forks of hardware/qcom/* repos that are pretty liberally spread with #ifdef's and makes them break CTS/CDD in a huge way). How much will these hacks be supported ?
4. Obvious point, what are the fields in which you need help most badly as of now. That is to say ril/telephony experts are highly needed right now or are features the topmost priority or is the highest concern to make the hardware repos tip-top so that devices are completely stable
Also publishing some guides on how to get sources and build the ROM would be good too, but since you are looking for "Developers" right now, it can be assumed that they will figure that much out on their own at least

This documentation will be done.
Actually one of the key goals of omni is to properly document things.
Bear in mind exactly how early this is in the process - it was only yesterday we even made the links available for github...
Documentation will be a large part of going forward and it has been ongoing for a while. Currently that's the biggest task actually, much moreso than the actual development.
Developers don't only write code, they also write docs
To that effect, http://docs.omnirom.org is going to be the home

Among other things I want to do is a "patches for a given feature" document so it's easier to find out how a given feature (such as status bar brightness) was implemented.
I really want to do it before I have too many patches to put in there, but I also have tons of stuff to fix!

Entropy512 said:
Among other things I want to do is a "patches for a given feature" document so it's easier to find out how a given feature (such as status bar brightness) was implemented.
I really want to do it before I have too many patches to put in there, but I also have tons of stuff to fix!
Click to expand...
Click to collapse
What do you think about this idea? These common kernel patches could also fit into that document.

pulser_g2 said:
This documentation will be done.
Actually one of the key goals of omni is to properly document things.
Bear in mind exactly how early this is in the process - it was only yesterday we even made the links available for github...
Documentation will be a large part of going forward and it has been ongoing for a while. Currently that's the biggest task actually, much moreso than the actual development.
Developers don't only write code, they also write docs
To that effect, http://docs.omnirom.org is going to be the home
Click to expand...
Click to collapse
if I can be of any help let me know,
I would love to see this project start off right from the beginning with proper documentation about EVERYTHING
also +100 to @Entropy512 's idea. documenting each feature and how it has been added is really important
I strongly urge that submissions via gerrit should be enforced to have a well written description in the commit message too. (it is so much easier now with gerrit 2.7+ we can do it right inside our browser after the patch has been uploaded too)

championswimmer said:
if I can be of any help let me know,
I would love to see this project start off right from the beginning with proper documentation about EVERYTHING
also +100 to @Entropy512 's idea. documenting each feature and how it has been added is really important
I strongly urge that submissions via gerrit should be enforced to have a well written description in the commit message too. (it is so much easier now with gerrit 2.7+ we can do it right inside our browser after the patch has been uploaded too)
Click to expand...
Click to collapse
Yup. I've always tried to have a detailed commit message in anything I create, but I think we may need to start enforcing it so everyone does it.

Is there any kind of current features / bugs / patches list on the official build? Or even just a changelog?

orangekid said:
Is there any kind of current features / bugs / patches list on the official build? Or even just a changelog?
Click to expand...
Click to collapse
There are no official builds yet. Too early for that.
so much work to do.

Entropy512 said:
There are no official builds yet. Too early for that.
so much work to do.
Click to expand...
Click to collapse
Oh, I was under the impression there was a compiled "official" version for the N4, N7, etc...
No worries, in due time I'm sure. Be looking forward to the Nexus 5 build..

orangekid said:
No worries, in due time I'm sure. Be looking forward to the Nexus 5 build..
Click to expand...
Click to collapse
give us the device first

I follow Omni for the Nexus 5. Nightlies have started since Monday so I'd like to know if there's a general Omni changelog now or a specific one for each device.

I'm a developer without much ROM/Android development. I'd love to give a hand wherever possible, but like @championswimmer said, it's kind of overwhelming to jump in and help. I'm totally cool to be relegated to documenting things if that helps, but I also understand the interruption that it would cause for you guys to slow down long enough to explain what I need to know.
What I do have experience with:
Java
Jenkins
Minimal app development
Other crap that might or might not be helpful