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.
Why are there so many galaxy forums?
I'm trying to understand because this forum http://forum.xda-developers.com/forumdisplay.php?f=1566
Is really busy, with a lot of android roms.
The ATT Galaxy S 3 android rom forums seem much smaller.
Why are these roms not compatible? Is the International version that much more popular?
The international has been out a lot longer than the US version. And they are not compatible due to different hardware.
Sent from my SAMSUNG-SGH-I747 using xda premium
While it may seem they're all the exact same, the various us versions have different radios and other carrier specific stuff. And remember, the international gs3 has been out since may, of course the devs are used it by now. The non-int versions really only just came out a week ago.
Sent from my SPH-L710 using xda premium
The international Galaxy S3 (i9300) is practically a different phone from any of the US variants, in terms of hardware. It uses a different SoC (system-on-a-chip; different processor and graphics processor) and different cellular radios.
The US variants are also all different in the regard that they each run slightly different software by default, but the only hardware difference is in the cellular radios. They share the same SoC, so it's feasible to port ROMs between them without too much work. This also applies to the Canadian variants and such, as they share the same SoC and hardware as the US variants, with the exception of those cellular radios.
The Verizon version is the black sheep in that it has a locked bootloader, and currently ROMs that utilize a non-stock kernel can only be flashed to it (and work) if a workaround is used.
The one & main reason that I m going to Give you is::::
For **Noobs** so they won't brick their phone.
appdroid said:
The one & main reason that I m going to Give you is::::
For **Noobs** so they won't brick their phone.
Click to expand...
Click to collapse
Reading skills are fundamental.
The majority of noobs read "The" then continued to brick their phones.
I was just wondering why CM11 has already been ported to the N9005 but not to the N900? Is it the Exynos sources or simply that no developers have ventured on that yet? In either case, thanks to the incredible developers on either phone that make them even better than they are, and do it all mainly for free
bandroid842 said:
I was just wondering why CM11 has already been ported to the N9005 but not to the N900? Is it the Exynos sources or simply that no developers have ventured on that yet? In either case, thanks to the incredible developers on either phone that make them even better than they are, and do it all mainly for free
Click to expand...
Click to collapse
It's both, for the most part. Samdung has a long and sordid history of providing incomplete and/or outdated sources for its Exynos devices in particular, and what impacts things to the greatest degree is probably the missing userspace drivers needed to make the major components (camera, etc.) work properly. They've burned the Open Source dev community so many times and so badly each time that even the best have basically given up and walked away from it.
Mods, please forgive me if this is posted in the wrong folder. I'm new to the forum and didn't see a folder that seemed more appropriate.
When referring to custom recoveries, is there any difference between the Tab 4 - - 7, 8, or 10.1? I cannot seem to find any recoveries officially supported, my device is never quite on the list. There also seems to be a lack of tutorials out there for the Tab 4. I've come across numerous ones for different iterations of the Tab series (Tab 2 is quite popular, I guess), or the tutorials will refer to a different model of the Tab 4, from a different cell provider.
Can someone point me in a direction on where to find a custom recovery for the Tab 4 from US Cellular (10.1")? Could someone also explain to me if there is or what there is for a difference between the different sizes/models of the Tab 4 that makes a difference in rooting/flashing the device?
And finally, on a side note, what are recommendations for which custom ROM to choose? As I'm sure someone will point out that it will depend on what I want the ROM to do, I'm mostly looking for personal preferences of those more experienced than me.
so..........
So it has been a while and no one has responded at all...
SplinteredChaos said:
So it has been a while and no one has responded at all...
Click to expand...
Click to collapse
Yes there is a big difference but you might ask one of the ops in the android development that has built a custom recovery if it would work for yours
Thanks
ddubz said:
Yes there is a big difference but you might ask one of the ops in the android development that has built a custom recovery if it would work for yours
Click to expand...
Click to collapse
Thank you for the reply. Do you know any of the specific differences?
SplinteredChaos said:
Thank you for the reply. Do you know any of the specific differences?
Click to expand...
Click to collapse
Not really but I do know the 7 inch uses a different processor chip than the 8 and 10 inch. But I am no developer and couldn't tell you if any of the custom recoveries would work for yours. What's your model number?
With all the apparently different variations on the S920, I am just curious as to why the S920L is not as popular with the customization and ROM's.
I have never seen such a model with so many different variations to make it nearly impossible to flash a ROM unless it is built specifically for the phone model itself.