I'd like to know where to start on making a CM12 compatible device (VS985/Verizon G3 in this case) work in omnirom, where to start? I already have knowledge in building ROMs but not doing a full port towards another ROM type (not a modified CM12 variant ROM) just to get that out of the way
Bump?
KShion619 said:
Bump?
Click to expand...
Click to collapse
Thing is, every device is different. Things that worked on one device might not work on another.
There are a few things where we can probably provide some "If you have this set in CM, you need to change it to that for Omni" - such as naming conventions for some of our CAF repos. These things are currently being redone for 5.1.
5.0 wasn't our proudest moment - a lot of us were mostly away for a good portion of the cycle, and we're just getting caught up now.
Also, in many cases, there might be patches to core repos needed for your device but none of our currently supported devices that require you to figure out what's missing - this can sometimes quite challenging.
In some ways, other than some basic hints about obvious differences, I don't want to provide TOO much detail, as for a device to be properly maintained it needs the maintainer to be independent and able to track down/solve issues themselves, as opposed to just blindly cherry-picking CM and applying some sort of step-by-step guide. Yes it's much more time consuming in the short term, but it allows a maintainer to truly learn the ins and outs of their device. We had a few devices in the 4.4 cycle where the maintainers blind-tracked CM and were not capable of anything more than basic cherrypicking, and the quality of those devices suffered.
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.
Hello! I have been studying a lot of topics related (if not required) to android ROM development since I was 15. I am age 18 now and I believe that I am ready to do what I set out to do when I rooted my first phone. I had originally purchased a nexus 4 to practice development on, only to have it suffer from irreparable water damage. I purchased the AT&T Galaxy S4 "jflteatt" to replace the nexus, and am currently using this phone. I have several questions and would appreciate any advice and input on how to further my knowledge of android development.
Is the S4 an ideal device to practice building from source and porting ROM's too?
Just how hard is it to "build from source"? I notice that most of the esteemed developers here on XDA have incredible experience in computer science fields.
I didn't list the experience I currently have because I would love for readers to list what areas they think are required to be an effective android developer. What areas would you suggest?
Is it acceptable to us a Virtual Machine to contain my Ubunut (64 bit) build environment? I plan on upgrading to a solid state drive when I can afford it. I have 8 out of 16 GB of RAM and 150 out of 500 GB of storage dedicated to my the Virtual Machine.
What would you suggest for a first project that I can do to get the hang of what non-app android developers do?
I am not finished with this post, I really need to go study for class and get off my XDA addiction. I am going to revisit this very soon to add anything I am forgetting and read the feedback.
NOTE: I have a tendency to really make people angry on XDA (well everywhere) without meaning to. So if I have offended anyone in any way shape or form, broken any rules, misplaced this thread, etc. Don't hesitate to let me know and I will promptly fix the problem to the best of my ability. I am very human and make mistakes, more than I care to admit.
I would say our s4 variant isnt the best choice, due to our locked bootloader...if you are on anything after MF3 than you wont even be able to test your source built roms since we have no real recovery after MF3.
With that said...your best device would be a nexus device...but looks like you already got the S4
And lastly, porting/buulding a preexisting rom from source is not that difficult, I have taken no computer science or coding classes and have successfully ported many roms through source.
Building your own custom rom from the ground based off pure aosp however is a diffenrt story and requires quite a bit if coding knowledge
Virtual machine will work, however dualbooting and building in a real linix environment will provide a faster build speeds
Hope that helps you...
Sent from my SAMSUNG-SGH-I337 using Tapatalk
mg2195 said:
I would say our s4 variant isnt the best choice, due to our locked bootloader...if you are on anything after MF3 than you wont even be able to test your source built roms since we have no real recovery after MF3.
With that said...your best device would be a nexus device...but looks like you already got the S4
And lastly, porting/buulding a preexisting rom from source is not that difficult, I have taken no computer science or coding classes and have successfully ported many roms through source.
Building your own custom rom from the ground based off pure aosp however is a diffenrt story and requires quite a bit if coding knowledge
Virtual machine will work, however dualbooting and building in a real linix environment will provide a faster build speeds
Hope that helps you...
Sent from my SAMSUNG-SGH-I337 using Tapatalk
Click to expand...
Click to collapse
Building from pure AOSP is my ultimate goal, I should have worded that better. Adding my own features to android (hopefully useful ones) is something I have always sought to be able to do. I don't want to sound as though I want to leach off of other's hard work rather than contribute. More than anything, I want to be able to make useful contributions! Just thought I would specify. On another note, thank you for your suggestion and advice!
Hi, I managed to build Cyanogenmod 11 for my device based on this guidehttp://wiki.cyanogenmod.org/w/Build_for_ks01lte#How_to_Build_CyanogenMod_.0Afor_Galaxy_S4_LTE-A_.28GT-I9506.29_.28codename:_ks01lte.29. The docs for porting omni seems to be really sparse and my device is an rather obscure model (GT-!9506). I am wondering what exact changes(other than the repos) do I have to make to the steps used to build Cyanogenmod in order to build Omni ?
Infinitelomeres said:
Hi, I managed to build Cyanogenmod 11 for my device based on this guidehttp://wiki.cyanogenmod.org/w/Build_for_ks01lte#How_to_Build_CyanogenMod_.0Afor_Galaxy_S4_LTE-A_.28GT-I9506.29_.28codename:_ks01lte.29. The docs for porting omni seems to be really sparse and my device is an rather obscure model (GT-!9506). I am wondering what exact changes(other than the repos) do I have to make to the steps used to build Cyanogenmod in order to build Omni ?
Click to expand...
Click to collapse
Depends on the device. Sometimes the device trees and kernel need very little modification.
In other cases, CM has commits buried in various places to handle "Samsungisms" (various odd quirks), some of which we may be missing for certain things to function.
On our wiki, we used to have some info highlighting specific things we did differently than CM, but many of those were handling "pure AOSP/CAF" vs CM's "hybrid AOSP/CAF" stuff for Qualcomms, and many of those issues disappeared in 5.0
Unfortunately much of the documentation never really got updated with 5.0 - 5.0 was a complete and total disaster/failure for us to be honest. We had a lot of team members tied up with other things/burned out for the entirety of the 5.0 cycle.
5.1 looks like it'll turn out much better but it's going to take some time for things to settle out.
In general, there's always a lot of trial and error for a device maintainer, which is partly why there aren't detailed step-by-step guides - it's partly that there is no way to write such a guide as each device is different, and partly because if someone has hope to maintain a device properly in the long run, they need the patience and investigative/troubleshooting skills to figure out a lot of this on their own.
In general, if you drop by on IRC when something goes wrong, people can try to give you pointers, but as i said - the beginning of the 5.1 cycle is going to be a time where lots of things break on occasion.
And if that's impossible , can someone kindly explain why? Thanks
Absolutely no.
HatRiGt said:
Absolutely no.
Click to expand...
Click to collapse
Yeah, I searched in forum and everyone says no, I'm just curious about the technical reason
Technically it's not impossible but the real problem is that the OnePlus 5 has never had a Marshmallow so there's no kernel source or device tree for Marshmallow on the 1+5. Developers use these things because it contains all the lines of codes needed to tweak and compile their own custom ROMs, having the original code is very important because it has all the necessary APIs needed to interact with every piece of hardware on the device. Since the 1+5 never had Marshmallow built for it that means in order for you to have a seamless experience like the one you expect from stable software, you have to build it from scratch or you could borrow the source from a similar hardware, like 1+3t. Problem is if you go that route, there are many hardware differences so you still have to spend a lot of time rewriting code, debugging, testing, and repeating all that over and over again and even then you probably won't get a couple of things working properly.
In simple terms, it would take an awful lot of time to port a software version that for many of us is already outdated for a device that never had that version and that would probably not run as smoothly as Nougat based Roms.
HueleSnaiL said:
Technically it's not impossible but the real problem is that the OnePlus 5 has never had a Marshmallow so there's no kernel source or device tree for Marshmallow on the 1+5. Developers use these things because it contains all the lines of codes needed to tweak and compile their own custom ROMs, having the original code is very important because it has all the necessary APIs needed to interact with every piece of hardware on the device. Since the 1+5 never had Marshmallow built for it that means in order for you to have a seamless experience like the one you expect from stable software, you have to build it from scratch or you could borrow the source from a similar hardware, like 1+3t. Problem is if you go that route, there are many hardware differences so you still have to spend a lot of time rewriting code, debugging, testing, and repeating all that over and over again and even then you probably won't get a couple of things working properly.
In simple terms, it would take an awful lot of time to port a software version that for many of us is already outdated for a device that never had that version and that would probably not run as smoothly as Nougat based Roms.
Click to expand...
Click to collapse
Get it, thanks very much my friendSo seems I have to wait for the Xposed for Noughat.Well, be patient
HueleSnaiL said:
Technically it's not impossible but the real problem is that the OnePlus 5 has never had a Marshmallow so there's no kernel source or device tree for Marshmallow on the 1+5. Developers use these things because it contains all the lines of codes needed to tweak and compile their own custom ROMs, having the original code is very important because it has all the necessary APIs needed to interact with every piece of hardware on the device. Since the 1+5 never had Marshmallow built for it that means in order for you to have a seamless experience like the one you expect from stable software, you have to build it from scratch or you could borrow the source from a similar hardware, like 1+3t. Problem is if you go that route, there are many hardware differences so you still have to spend a lot of time rewriting code, debugging, testing, and repeating all that over and over again and even then you probably won't get a couple of things working properly.
In simple terms, it would take an awful lot of time to port a software version that for many of us is already outdated for a device that never had that version and that would probably not run as smoothly as Nougat based Roms.
Click to expand...
Click to collapse
Well said. Thanks fur the explanation. I don't even own an OP5 but was considering it..... Might have to give up Xposed finally
Ramaness said:
Get it, thanks very much my friendSo seems I have to wait for the Xposed for Noughat.Well, be patient
Click to expand...
Click to collapse
Unfortunately I don't think Xposed will ever make it to Nougat, and as for android O, I wouldn't bet on it being released anytime soon after O's official release.
The closest thing to Xposed modules that work on Nougat are the Magisk modules, Magisk is a type of systemless root that has support for modules that work similarly to Xposed. I suggest you read up on it and se if it is something that can work you.