Related
I'm new to Android but not new to Linux and wondering what is necessary to get these ROMs (and others) working on the CDMA Hero. What are the major differences, proprietary drivers? Kernel modules?
New Cyanogen ROM, just released
http://forum.xda-developers.com/showthread.php?t=567610
In other words, what's stopping us from running these ROM's right along with G1/Dream users?
I'm curious also... would love to try his roms...
Since Android 1.6 was supposed to add CDMA support I would think they should work as well as 2.0 unless the developers have taken the cdma support out of the code in their roms to shrink the size to fit on the G1's.
If I had a Hero I would be giving it a try most likely. I might try picking one up this week since Best Buy has them down to $99. I just wish it had a keyboard.
I'll try when I get home from work.
On a side note, even if this rom doesn't work, I should be able to boot into the recovery rom no matter what... riiiiiiight?
herzzreh said:
I'll try when I get home from work.
On a side note, even if this rom doesn't work, I should be able to boot into the recovery rom no matter what... riiiiiiight?
Click to expand...
Click to collapse
Correct! The recovery image isn't touched by normal ROMS typically.
I'm tempted. Can this be applied right over the MoDaCo ROM?
I have tried a couple things with these. I tried flashing it outright. Wouldnt get past the initial htc boot screen. So I replaced the kernel in the boot.img of Cyans rom with ours, that still didnt work. Then I tried replacing the entire boot.img and still no boot working. I think Donut uses the 2.6.29 kernel or whatever it is. Ours is .27 so I think we would need to recompile the .29 kernel and pray our drivers work with it. Please, someone else try it too and see if they can get it working. I would love you forever if you could. If not, we will just have to wait until HTC gets us Eclair.
Thanks
Thanks for trying this, chuckhriczko and others.
I'm mainly coming at this from the pure Linux point of view: shouldn't these ROM's run anywhere (barring proprietary bits)? Shouldn't we be able to "share and share alike" between platforms, Hero/Dream/G1/whatever? If there is a chip architecture difference, fine then we need a recompiled kernel. Obviously there is also the question of firmware, but that's a given on all phones.
Otherwise, shouldn't these ROM's be fairly universal? Or if they are not, I'd like to know what makes ROM building such a unique endeavor for each phone.
5tr4t4 said:
Thanks for trying this, chuckhriczko and others.
I'm mainly coming at this from the pure Linux point of view: shouldn't these ROM's run anywhere (barring proprietary bits)? Shouldn't we be able to "share and share alike" between platforms, Hero/Dream/G1/whatever? If there is a chip architecture difference, fine then we need a recompiled kernel. Obviously there is also the question of firmware, but that's a given on all phones.
Otherwise, shouldn't these ROM's be fairly universal? Or if they are not, I'd like to know what makes ROM building such a unique endeavor for each phone.
Click to expand...
Click to collapse
I believe it's mostly the proprietary drivers for some of the hardware as well as needing a kernel recompile...once HTC releases the CDMA kernel, I'm sure we'll see a lot more (that or some genius will reverse engineer it...either way!)
The other thing to consider is that most of these ROMs are based on something...they take what's existing and tweak the heck out of it (I'm willing to bet that the vast majority of ROMs can trace their roots back to an official vendor image at some point).
I'm actually trying to setup a build environment and poke around but I'm starting from ground zero on the mobile platform side of things so I wouldn't hold out for me (and finding a Java 1.5 runtime is surprisingly hard these days ).
I'm noticing that we're seeing more and more ROM's pop up (primarily gutted ROMs focussed on eeking more speed as opposed to MoDaCo who went for more features).
thecodemonk said:
I believe it's mostly the proprietary drivers for some of the hardware as well as needing a kernel recompile...once HTC releases the CDMA kernel, I'm sure we'll see a lot more (that or some genius will reverse engineer it...either way!)
The other thing to consider is that most of these ROMs are based on something...they take what's existing and tweak the heck out of it (I'm willing to bet that the vast majority of ROMs can trace their roots back to an official vendor image at some point).
I'm actually trying to setup a build environment and poke around but I'm starting from ground zero on the mobile platform side of things so I wouldn't hold out for me (and finding a Java 1.5 runtime is surprisingly hard these days ).
I'm noticing that we're seeing more and more ROM's pop up (primarily gutted ROMs focussed on eeking more speed as opposed to MoDaCo who went for more features).
Click to expand...
Click to collapse
What OS are you using? If your using a Debian based linux then you can get it from the Debian Lenny repositories. One word about this though, it killed my existing Java 1.6 so I had to reinstall it when I needed it. Otherwise that works.
And yeah, we are primarily doing gutted roms because that is all we know up to this point. It is very difficult to find help from those who know all about recompiling a kernel and things like that. Like I said, I couldnt get Cyanogen to even boot on my phone but obviously, it should at the very least do that. But only one dev on these forums ever helped me with my CDMA roms and that was Mlign from the Dream forums. Everyone else (understandably busy) ignored me. Im not saying anything bad about them but it's just harder for people to learn. Patience will give us what we desire though.
vendor tree for cyanogen heroc
im a noob and dont know how to build it but its here:
http://github.com/darchstar/vendor_cyanogen_heroc
Thread gravedigging much?
yes haha i want cyanogen on my hero lol
I'm hoping somebody will be able to educate me a bit here on some deep technical questions. I've been searching for some information on this topic for a while now but without any luck. In a nutshell what I am curious about is this.. if I were to, lets say, build my own new handset, what would be entailed in getting android to work on it?
I know a kernel must be built with all the drivers and modules to communicate with any specific hardware/radios etc. But once you've got the kernel, is there still more porting that has to be done in the core android code? Are there significant CPU architectural differences or some other major differences between handsets that require more porting within the rest of the OS code? (Side question: if I want to build a kernel from source, what tools do I need)
To ask my question more specifically with the Epic, what is going to be necessary to get Gingerbread on it? If we already have the source for Eclair, or when we get the source for Froyo on the Epic.. what is it that makes it more than just a matter of pulling the drivers from those versions to make things work. Is android not built in a modular enough way to enable that?
I am myself a developer, but as I'm sure is obvious from my questions.. I'm not very experienced at OS level development. And what limited knowledge I do have mainly comes from making correlations to desktop OS, which is probably what is leading me astray.
I'm just really craving to know more about this stuff, so thanks ahead of time to anyone who takes their time to school me and help me understand. If there is any material out there that I should just go RTFM, I'd like to do that but please point me in the right direction.
Thanks!
FYI, your post/s do not pertain to any direct development. They are just generalized questions that can be answered with a simple search.
See Here
Reported as belonging in Q&A/general.
The most difficult part is porting drivers (if they're not already part of the kernel mainline) and device-specific glue code to the new kernel base. This is difficult becuase (i) it's a fair amount of code, (ii) the kernel does not have a stable API, so the necessary changes may be somewhat far reaching, and (iii) bugs that crop up are often more difficult to pin down and fix than in userspace programs. It also doesn't help the matter that Samsung's portion of the kernel code is messy, buggy, and just generally not in a state that would make it easy to port over to a new tree.
The reason why we can't just port Eclair drivers to Froyo, or Froyo drivers to Gingerbread, is that there's a fair number of proprietary modules on the phone (LCD, WiMAX, the entire storage stack, etc.) to which we don't have the source code. These modules are compiled against a specific kernel minor version (e.g., 2.6.29 for Eclair) and won't load in Froyo or Gingerbread. The version number can be faked, but if there's any change in the module API, or in the "API" (which isn't even formally defined) of dependent kernel code, all bets are off.
In theory if there's any Galaxy S device with a Gingerbread release, it might be possible to get a limited-capability kernel up and running, depending on how much the proprietary drivers change across devices (hopefully not much). The Nexus S doesn't count though as Google replaced the entire proprietary flash stoage stack with a GPL-based one. While we might be able to get such running on Galaxy S hardware, it would be incompatible with the existing storage layer and would necessitate a full device flash. Not really something you want to do when an official update with a complete set of drivers is going to be made in the "near" future.
Aside from the kernel, you would have to modify the parts of the Android userland that interface with hardware specific components, for example the "4G" (WiMAX) settings menu and such. I think much of the modem interaction also happens in userland. Then you have to port over whatever custom skin (e.g., TouchWiz) you have.
For some reason this is often believed to be the most difficult and time consuming part of a port, i.e., it's commonly complained that "HTC & Samsung delay releases to port Sense & TouchWiz, if they just dumped them and went AOSP updates would be a lot faster." Honestly it's not. It's an API update like any other Android app, and third party launchers don't seem to have significant problems here.
Mind you, I mention the difficulties of kernel porting without having actually attempted to do it myself, largely becuase it is so daunting. I know there's folks interested in doing this, and perhaps they have some tricks that make it a bit easier in a specific scenario. In general though, these are the difficulties one enounters when trying to port new Linux versions to any embedded platform.
I've often wondered this myself, as well as wondered why Google seemed to get caught with their pants down.
Now granted I don't know the nitty gritty details, but I don't understand why android wasn't written in a manner where as much of it as possible is just apps, and anything that is core is written where the handset makers just need to do the very low level stuff.
On top of that then it could have been made to be more easily themed, even rather dramatically.
Samsung/HTC should only be maintaining the low level "android wants the gps location, I know how to work this specific chip and give it back" and Sense/TouchWiz should just be a theme, and some custom widgets. Android itself should be virtually untouched between those two layers, and updates that don't change how it has to interact with the hardware or the themes should come straight from google.
Thankfully things have at least started to move this way. (you don't need to roll out a ROM update through sprint because Google updated the market like you used to, etc)
If Dell wants to customize Win 7 they add onto it, they don't roll their own copy of it, creating god knows how many fragmentation issues in the meantime. (And yes, I know Windows isn't open source, so they can't, but you get what I'm saying.) Because the second they did that they'd then take on a much larger QA burden, on top of everything else.
If android is untouched for the most part, it works, or it's a bug for everyone. You'd only need to test calls to your low level updates, which could for the most part be automated. The second you start changing a line here and there in the source code, now all of a sudden you have to do the "If I make a calendar item while on a call on a leap year the phone reboots" type QA/Support as well.
Edit: And of course it's very possible that is more or less how it is and the handset makers just flat out take longer to update then anyone imagined they would.
What language/s do you have to know to do all this?
nubsors said:
What language/s do you have to know to do all this?
Click to expand...
Click to collapse
C for kernel and Os. Java for apps(sdk). C and java(ndk/sdk) for apps that require native code implementations of things (eg. The VLC player that is coming. It wasn't possible until the latest edition of the ndk.)
Sent from my SPH-D700 using XDA App
Thank you mkasick for a great detailed answer. I didn't think about the fact there are closed source drivers to worry about as well, and that explains a lot.
@ghostrid3r: I did plenty of simple searches which did not answer my questions before posting, but thank you for the link. Also, not that it matters to me.. but is the development section just for releasing custom roms or something? If questions directly pertaining to development details don't belong there, seems to me the section should be renamed to "Epic 4G Custom Roms" instead.
Hey all!
I`ve been lurking for some time now, but finally decided that I want to try and improve some small part of the kindle experience.
I know java, c and c++ and would like to work on the hardware/software layer(kernel etc.).
My question now is, where to start?
gedemis said:
Hey all!
I`ve been lurking for some time now, but finally decided that I want to try and improve some small part of the kindle experience.
I know java, c and c++ and would like to work on the hardware/software layer(kernel etc.).
My question now is, where to start?
Click to expand...
Click to collapse
Wait, you want to develop on kernels? Or ROMs? I would suggest starting here on ROMs: CM9 Building. How many years of experience do you have? What is your work environment (Ubuntu, Xubuntu, etc.)
Well anything that`ll get me coding. I`ve mostly done school-related programming thus far, and would like to delve into some more advanced stuff where I might make a difference
Currently running Ubuntu or Windows/Cygwin.
Thanks for pointing out the ROM building, I will definitely look into that!
Sent from my Kindle Fire using XDA
I recently saw on one of the blogs, that one of the expected and widely rumored feature of the android jellybean will be Android Mainlining. I don't exactly know what it is because I am not a dev. But i feel it will help in development for our galaxy 3 and that the future releases of android and/or kernel (3.3+) would be much more easier to get to work on our device. I hope some dev confirms this. If it happens to be so, then will we be able to get the latest android and kernel versions easily and fast ??
AndroidPolice mentions --"Linux and Android Working TogetherThe one definite Jelly Bean bit of news is an upgrade to a fresh Linux Kernel. Android is built on Linux, but it has traditionally been a fork of Linux. Linux 3.3 marks the start of the Android Mainlining Project: the merging of the world's most popular Linux-based OS with the proper Linux Kernel. 3.3 should let you boot directly into an Android user space with a stock kernel, and 3.4 will bring even more Android stuff (like power management) into the fold. This should increase Android's hardware compatibility, make life easier for developers looking to port Android, and help out Linux distributions that want to support Android programs.
If you are at all interesting in why forking the Linux Kernel is a Very Bad idea, watch the first few minutes of this awesome talk from GKH, a Linux Kernel developer. Basically, Linux development is scary fast, like 7600 line changes per day fast, and you want to be on that train, not chasing it.
So life for Googlers should get a lot easier. You know how OEM modifications slow the upgrade process when Google releases a new version? How they have to re-port all of their changes to the new OS, and it usually involves lots of duplicated effort? Google has basically been doing that, this whole time, with the Linux Kernel. Having Android be officially supported should allow our beloved Android engineers to spend less time merging all those kernel changes and more time developing awesome features."
The part I got was that, they're merging Linux and the android kernel together for better compatibility with hardware. Not sure how it links to easier porting or maybe easier porting after jellybean.
Sent from my GT-I5800 using XDA App
Hi
I have a weird question...
Is it possible to port (?) an Android Wear ROM to android smartphone? I mean, I have an old X8 which is nothing but catching dust on the shelf. I thought about I can use it as a smartwatch (it is small enough ). But as it is on normal cyanogenmod, it cannot be like watch. So as I wrote above, is it possible to flash such a rom on normal android smartphone?
Sorry for asking stupid questions and thanks for any replies
Excellent idea.
+1
Bump
Any answers? Please
I'm sure it's possible because Android Wear is still Android at the core, would probably require a lot of work, rewriting the kernel, getting drivers to work, etc. and AFAIK there is no source code for the OS, only the kernel, so that would make it even more challenging.
Now that is the info I wanted
Thanks @DarkRazorZ
Theoretically, couldn't you use the Wear launcher with an app that intercepts your phone's notifications?
Theoretically yes, but in practice it is not as good as whole rom. I used that launcher when it was as preview and it wasn't good but it wasn't bad either. I just wanted to know if porting (or building?) similar rom for very small phones is possible
I think everything is possible, but keep the original ROM