I apologize for my noobish question, but how are the ASOP builds starting to roll out w/o source being released?? I understand you can compile aosp builds on your own, but doesnt the source code provide all the tweaks you need to optimize it on a device to device basis?
There's no ICS source for the Captivate either, but we are officially supported on CM9. Very glad!
Sent from my Captivate using Tapatalk!
if there is good source from another device that is near this one then porting could be possible.
The short answer is a combination of two things based on what I can tell.
They are actually using the existing kernel for the leaked ICS roms and beginning to dissect them. As far as I know, the current AOKP roms being used are using either an unmodified original kernel from ULD3 or 'very slightly' modified/patched kernel from ULD3 with a few tweaks for overclocking support and whatnot.
As far as what is happening with the Captivate, I believe they are taking heavy sections from the Gingerbread source code and splicing it in to their ICS kernel and changing what they need to for ICS compatibility.
Also, similar devices that have ICS source code floating around can also be spliced up.
I am only speculating here since I am not involved in the projects, if someone knows more than I, feel free to speak up.
Related
Just curious as to which dev you think will put out the first stable rom based on t959 source? Not that first or fast is best, but i am sure they are all runnin on hyper-speed. My guess is dfa. I am a fan of all the big 3, but Masters updates are on point. Obviously Eugene killed the kernel race(nice job).
Blue 32 in the 4th.
My guess is Whitehawxx and or untermensch will have a deodex version out today
Then Einherjar/trigger/TW and Master team will get something out who know between those 3
I think they are all more surprised how much the leaks were right......
Isn't trigger part of the enjijar team?
And trigger is by bricked?
What the hell? it's kernel source, not Rom source....
Sent from my SGH-T959 using XDA App
No it's the entire FroYo source.
The ROMs here are fine, the kernels are the ones we needed the source for as they used to be based on the i9000 JPX FroYo source which hogged battery.
Our source is based on KA6 FroYo which should equal to better life!
Alanrocks15 said:
No it's the entire FroYo source.
The ROMs here are fine, the kernels are the ones we needed the source for as they used to be based on the i9000 JPX FroYo source which hogged battery.
Our source is based on KA6 FroYo which should equal to better life!
Click to expand...
Click to collapse
NO, no it's not. It's KERNEL SOURCE. the only rom source we have is from google.
It's source for a froyo kernel build KA6. Nothing more.
Can a experienced user please respond and tell us if its kernel source or froyo source???
i know what i'm talking about. it's kernel source. nothing more.
If it was rom source, then the GT-i9000 would have had rom source for a while. they've only had kernel source. And that's what we have now. kernel source.
If you don't believe me, then download the source and try to compile it yourself. you'll only end up with a kernel.
the only rom source we have is the AOSP source from google.
Time to set everyone straight.
It's Just KERNEL SOURCE!
The Platform dir within the source has NOTHING to do with a ROM, hell, doesn't even have anything to do with the kernel either.
Yes kernel code, but an intergeated kernel in one of these roms first was my poll question, not a flashable kernel. Thats all. Sorry to confuse.
feckmu said:
Yes kernel code, but an intergeated kernel in one of these roms first was my poll question, not a flashable kernel. Thats all. Sorry to confuse.
Click to expand...
Click to collapse
It's already done
You guys really crack me up.lol Not everyone even if they read tutorials, actually understand some of the foreign (Technical/Terms) language that some of you guys speak. Some of you have unbelievable arrogance to assume that everyone speaks geek. I do understand most of what I have read here and have been able to make my Vibrant really preform much better than stock. But not all are able to. Some in fact do need to be hand held a little. But if that is not your thing then ignore them when they ask for help. But to belittle demean and flat out act an ass on a public forum is ghetto fabulous. I'm in healthcare and I know that even when I am trying to speak in simplistic terms that I still talk over most patient's heads. It's up to me to try to help them understand the best way I know how. So why don't some of you get your asses off of your shoulders and stop trippin'
FAIL hahahaha
I've asked in two ROM threads and nobody seems to know... why do the ICS and JB ROMs all use the Froyo kernel? According to Wikipedia's article on Android history, ICS uses Linux kernel 3.0.1 and JB uses 3.1.10. However, both JB ROMs I've tried (Paranoid Android 1.95 and joker's CM10 0.1.1) use 2.6.32.9, which the article says is the Froyo kernel. Shouldn't we at least have the 2.6.35 kernel Gingerbread comes with? Why Froyo?
Just wondering. I'm not even sure why it matters, or if it matters. A fellow geek just thought it was weirder than having 102% battery when fully charged, so I figured I'd ask.
Dark Reality said:
I've asked in two ROM threads and nobody seems to know... why do the ICS and JB ROMs all use the Froyo kernel? According to Wikipedia's article on Android history, ICS uses Linux kernel 3.0.1 and JB uses 3.1.10. However, both JB ROMs I've tried (Paranoid Android 1.95 and joker's CM10 0.1.1) use 2.6.32.9, which the article says is the Froyo kernel. Shouldn't we at least have the 2.6.35 kernel Gingerbread comes with? Why Froyo?
Just wondering. I'm not even sure why it matters, or if it matters. A fellow geek just thought it was weirder than having 102% battery when fully charged, so I figured I'd ask.
Click to expand...
Click to collapse
Because of the lack of what the devs need. We would need to wait for the official Atrix/Photon ICS leaks to get those kernels
Sent from my undervolted, underclocked, power saving Motorola Atrix.
tatperson said:
Because of the lack of what the devs need. We would need to wait for the official Atrix/Photon ICS leaks to get those kernels
Sent from my undervolted, underclocked, power saving Motorola Atrix.
Click to expand...
Click to collapse
Try not to think of it in terms of Android versions, but rather, Linux Kernel versions. I believe it is because the 2.6.32 kernel is considered near perfect in terms of stability. Many Linux distributions use that kernel when they want to offer an extremely stable experience to their user base. For bleeding edge features but less stability, most distributions will use version 3+ of the Linux kernel. My guess is that since it is a standard of sorts because of being well-tested, it's just easier to rely on until we are provided with a later version. Just my two cents.
And why wait for Google release of Android 5.0? Why won't we do it ourselves.
tatperson said:
Because of the lack of what the devs need. We would need to wait for the official Atrix/Photon ICS leaks to get those kernels
Sent from my undervolted, underclocked, power saving Motorola Atrix.
Click to expand...
Click to collapse
Well, that would make sense if we had the GB kernel, 2.6.35. We have the Froyo kernel, and, AFAIK, there's not even a Froyo ROM for the Photon. Why would there be? It's a Gingerbread phone.
Acvice said:
Try not to think of it in terms of Android versions, but rather, Linux Kernel versions. I believe it is because the 2.6.32 kernel is considered near perfect in terms of stability. Many Linux distributions use that kernel when they want to offer an extremely stable experience to their user base. For bleeding edge features but less stability, most distributions will use version 3+ of the Linux kernel. My guess is that since it is a standard of sorts because of being well-tested, it's just easier to rely on until we are provided with a later version. Just my two cents.
Click to expand...
Click to collapse
This makes sense, and I understand what you mean about Linux kernel versions. I understand the kernel is modular. Once when I was trying Ubuntu, I got a kernel update. Didn't affect anything, just had to reboot. Couldn't tell what it changed.
Also, I just noticed that AOKP Build 8 uses kernel 3.0.1, according to the screenshot on the left. Kinda torn on trying AOKP. On one hand, I'm not a "pink unicorns" kind of guy. On the other, the default wallpaper and status bar icons are nice. Another AOKP ROM featured a pretty cool textured status bar. But when I asked what AOKP had over CyanogenMod, the only answer I got was "swagger". In fact... well, that's a completely different topic. New Topic button, here I come. Hopefully the powers that be will see this as valuable conversation, not spamming up the boards...
//edit: AOKP screenshot lies, it uses the same kernel as the rest (screenshot is of another device, to be fair).
Dark Reality said:
Well, that would make sense if we had the GB kernel, 2.6.35. We have the Froyo kernel, and, AFAIK, there's not even a Froyo ROM for the Photon. Why would there be? It's a Gingerbread phone.
This makes sense, and I understand what you mean about Linux kernel versions. I understand the kernel is modular. Once when I was trying Ubuntu, I got a kernel update. Didn't affect anything, just had to reboot. Couldn't tell what it changed.
Also, I just noticed that AOKP Build 8 uses kernel 3.0.1, according to the screenshot on the left. Kinda torn on trying AOKP. On one hand, I'm not a "pink unicorns" kind of guy. On the other, the default wallpaper and status bar icons are nice. Another AOKP ROM featured a pretty cool textured status bar. But when I asked what AOKP had over CyanogenMod, the only answer I got was "swagger". In fact... well, that's a completely different topic. New Topic button, here I come. Hopefully the powers that be will see this as valuable conversation, not spamming up the boards...
Click to expand...
Click to collapse
AOKP has more features than cyanogen, and dont mind the pink unicorn. Its only a boot animation. And the AOKP team changed it here recently so it really doesnt look as obtrusive as it used to. CNA happens to be my personal favorite.
Well, I kept the boot animation from CM10, which I really like, so whatever ROM I stick with will probably just use that, unless I find something better.
Using AOKP now. A little annoying that I can't add lock slider items, but I can live with it. I see what they mean by swagger -- it's a toggle. I think it's like "Awesomeness Detection" in Rockband 2. That is, a toggle option that does nothing but confuses the user or makes them think they're doing something special. A placebo. But in reality there is no code to it. (I'm assuming about AOKP. Harmonix confirmed this about Rockband 2 -- 3 years after the game shipped.) But yeah, boot animation is fine for now (if a little small). And I'm actually using an AOKP wallpaper. It's the one with the shadow of the guy with the swords. Pretty awesome. (Is that what UnicornPorn.apk is? The wallpapers?)
Curious about CNA but I'm going to give AOKP a few days to settle in. Battery is a big thing for me though.
its actually a nvidia thing, i imagine a quick google search between linus and nvidia will tell ya how he feels about them ;P. (if you dont believe me the transformer lineup has 2.6.39 as its ICS kernel)
you can use any kernel version you want so long as it has all the proper stuff in it, the big thing most people overlook tho is not a lot of people look at the linux kernel and see all the commits. which if you are making kernels i highly suggest you do as there was some awesome battery saving stuff in 2.6.38 as well as some overall speedups.
the version number changing is used to signify a stable release. like 3.0 or 3.1, 3.2 etc.
its entirely possible (hell sometimes needed for some kernel sources) to take what the OEM provides take the corresponding linux kernel (in this case 2.6.32) and overlay the oem code. the reason why most dont do it is cuz it takes a long time. once you have the linux tree merged with your device specific files you can then backport patches much easier.. and at that point you could have a 3.x kernel using the same 2.6.32 stuff from the oem. wont help you overall on booting and fixing camera etc in ics but it will give ya plenty of improvements in just the kernel itself
Dark Reality said:
I've asked in two ROM threads and nobody seems to know... why do the ICS and JB ROMs all use the Froyo kernel? According to Wikipedia's article on Android history, ICS uses Linux kernel 3.0.1 and JB uses 3.1.10. However, both JB ROMs I've tried (Paranoid Android 1.95 and joker's CM10 0.1.1) use 2.6.32.9, which the article says is the Froyo kernel. Shouldn't we at least have the 2.6.35 kernel Gingerbread comes with? Why Froyo?
Just wondering. I'm not even sure why it matters, or if it matters. A fellow geek just thought it was weirder than having 102% battery when fully charged, so I figured I'd ask.
Click to expand...
Click to collapse
well from a laymen point of view i run and love most of th3bills roms(PORTS) from jokersax.com and considering my mopho(photon) is over a year old and getting almost 7000 antutu and 4000+ quadrant scores(which makes a new GALAXY NEXUS STOCK LOOK SLOW)...i don't care what kernel when im blazing like that.lol If its kicking azz dont fix
Hi guys
I'm aware of CyanogenMod, but is it possible to have a completely stock JB ROM with no mods (other than busybox, deodexing, etc..) or custom apps installed? I can't seem to find one
Cheers
The community will correct me if I'm wrong, but I believe you'd have to build from source (AOSP) if you wanted something that is super-vanilla and hasn't been touched by a manufacturer outside of CM, AOKP, etc.
That said I also believe this particular question should be posted in the General or Q&A sections, for future reference.
djmatt604 said:
The community will correct me if I'm wrong, but I believe you'd have to build from source (AOSP) if you wanted something that is super-vanilla and hasn't been touched by a manufacturer outside of CM, AOKP, etc.
That said I also believe this particular question should be posted in the General or Q&A sections, for future reference.
Click to expand...
Click to collapse
Thanks for the reply
I mean Android was made to work on all devices right, but does CM do something like adding "drivers" (or the equivelent)? Is that what developers do when they "port" something like a new ROM that has been released on a similar device?
If multiple devices have a stock Android JB ROM, and they're also using a Tegra 2 CPU (and I'm guessing they all use the same type of RAM) etc.. is it quite easy to port? Do you have any idea how difficult it would be to compile it from source/getting it to run on a device?
I'm into technology, but without some serious research, I wouldn't have a clue where to start unfortunately
P.S. Yeah I realised after, already reported it to be moved
I've never ported between devices, but I've read enough to say confidently that things can be tough if you are porting between devices that are too different. At the very least you should stick between manufacturers...like it would be easier to port from Galaxy S2 Hercules to S2 Skyrocket for example than it would be from S2 to HTC xxx. There are quite a few good guides that explain how to port safely as long as the board configs and other important stuff are the same. If you aren't sure, don't do it.
For compiling from source, do a search on XDA here for shenye's guide "Compile JB on Ubuntu" - it was also featured on XDA TV. It's very helpful. Compiling isn't all that hard, but takes time and patience especially if you are working on a non-flagship device. It will likely take much research to find the right repositories for your device and vendor config, plus time to fix any errors the compiler reports.
Good luck!!
As soon as the at&t 4.1.2 jelly bean update was available i had it flashed, and for the most part, im happy, not as snappy as the 4.2.2 rom releases but HDMI out works on it along with the other bells and whistles.... what i was wondering was when do we start seeing roms that are based on that att release...is it the source code that the devs are waiting on? Just curious......the devs do an amazing job, its unreal...i give them so much credit..
here's one...
So we're starting to see already.....
I'm hoping AOSP based roms actually start taking advantage of our 4.1.2 kernel soon. Granted, CM merged some stuff from it, but from what I read in the CM nightly thread, they'd have been better off with the blobs and bases they were using rather than trying to merge all the skyrocket stuff. Perhaps they think more longterm than I, though.
Yes yes, you may think that I'm crazy for attempting to compile AOSP, but in fact im just obsessed with getting AOSP to work (on my previous device I spent a full year on it without success), thanks to the experience I know much more know about the environment.
I've done several pure aosp builds so far, and they result in a ~280mb system folder, which is kinda the size of aosp I guess (atleast for xxhdpi)
But they end with errors of course, anyways. I used the devices specs with updated overlays,and added dependencies (such as hardware) to the environment.
But since the aosp environment is very mean to new devices its once again a real struggle. as expected, but I like the challenge.
Anyways, Im currently trying out this hybrid-ish environment. which contains the items listed above but with several elements of the AOKP environment added (only the essential ones for compatibility).
Compiling goes so far so good. hope I will get a working build. (don't expect this to happen tho)
Oh and since samsung is releasing the S4 Google Edition (AOSP) soon it must be possible. (the google edition is the qualcomm varian afaik)
More info soon!
I'm going to drop this here for now until I have time to mess with it more.
https://groups.google.com/forum/?hl=en#!topic/android-building/_F67iLDcVzQ
Note: This leads me back to my previous question as to how we are supposed to build with this.
At face value it seems we're only getting fairly close to what we were with other OSRC releases.
Going to look at more later tonight.
Skilled devs can get pure aosp to work properly. It was done for sprints gs3 without using CM code.
Sent from my SPH-L720 using Tapatalk 2
You don't necessarily need proprietary binaries to be released to build AOSP, although it does make it much easier. Sometimes you have to resort to trial and error and debug tools.
drewX2 said:
You don't necessarily need proprietary binaries to be released to build AOSP, although it does make it much easier. Sometimes you have to resort to trial and error and debug tools.
Click to expand...
Click to collapse
I disagree completely. Without the prop' libraries and drivers that the OEM has built to manage the board you can most certainly expect the related hardware to fail or be only partially functional at best. Some other 3rd party generic driver would still be required if this example were true. In the good old AOSP days (maguro for example) had roughly a dozen proprietary files required for the device tree to build. With more and more OEMs making different hardware configs and spin-off APIs trying to lock down a lead in the game it has inflated that number greatly. In this instance, for example, S4 requires roughly 165 proprietary files in the vendor/ and device/ tree. Furthermore, with many of those stacks being required to pass for a successful boot complete (audio for example) there is little chance for even semi-functional usage without the required libraries and drivers.
broodplank1337 said:
(edit)...I'm crazy for attempting to compile AOSP...
Click to expand...
Click to collapse
We're compiling pure AOSP already for this board. I'm not sure what your repo structure looks like but if you are based off a CM or AOKP base clone then you got some work cut out for you. The CM tree compiles completely different than AOSP. All EaglesBlood builds are compiled from our same main branch, which consists entirely of only pure AOSP + our own EB coding. There is no CM codeblock nor anything else polluting (no pun). Since CM and others have some custom hybrid APIs and such you may run into issues that are difficult to resolve or even identify. If you aren't the one committing those patches then it is difficult to know at a glance of what has been heavily CM-ified vs closer to native code; or unless you're very in-tune with CM, gerrit and GIT.
We'll be releasing AOSP 4.2.2 as soon as we get the kernel config where we want it to be. Stay tuned. http://www.eaglesblood.com
oOo B0XeR oOo said:
I disagree completely. Without the prop' libraries and drivers that the OEM has built to manage the board you can most certainly expect the related hardware to fail or be only partially functional at best. Some other 3rd party generic driver would still be required if this example were true. In the good old AOSP days (maguro for example) had roughly a dozen proprietary files required for the device tree to build. With more and more OEMs making different hardware configs and spin-off APIs trying to lock down a lead in the game it has inflated that number greatly. In this instance, for example, S4 requires roughly 165 proprietary files in the vendor/ and device/ tree. Furthermore, with many of those stacks being required to pass for a successful boot complete (audio for example) there is little chance for even semi-functional usage without the required libraries and drivers.
I think you misunderstood what I said. First of all, I am speaking from *experience*. I have ported AOSP to devices without RELEASED proprietary binaries and I have handled every step in porting; from display, audio, to calling, wifi, bt, etc. Released means the manufacturer provides a nice little package for you. I had to in many cases, figure out which libs from a stock rom were needed. Additionally, you can utilize libs from completely different devices as a temporary patch. I am very comfortable with kernel development and the android framework. If you were too, you would know what I am saying is true. Here is one tip, nearly every board is like another (within the same class; eg. MSM8960, APQ8064) with only slight variations (e.g. modem). Once you understand that, it becomes easier.
We're compiling pure AOSP already for this board. I'm not sure what your repo structure looks like but if you are based off a CM or AOKP base clone then you got some work cut out for you. The CM tree compiles completely different than AOSP. All EaglesBlood builds are compiled from our same main branch, which consists entirely of only pure AOSP + our own EB coding. There is no CM codeblock nor anything else polluting (no pun). Since CM and others have some custom hybrid APIs and such you may run into issues that are difficult to resolve or even identify. If you aren't the one committing those patches then it is difficult to know at a glance of what has been heavily CM-ified vs closer to native code; or unless you're very in-tune with CM, gerrit and GIT.
We'll be releasing AOSP 4.2.2 as soon as we get the kernel config where we want it to be. Stay tuned. http://www.eaglesblood.com
I agree with you on some points about CM code, however, you're group has been porting devices that were working or nearly working with base android code. Talk about an easy route. I can see you haven't had to do any hard work yet. Going from 4.1 -> 4.2 on a non google AOSP supported device or a device that has no CM build available for it is a whole different story. How do I know? I've done it. I was the first to build CM for HTC DNA and both CM/AOSP for Oppo Find 5. Next time before you "completely disagree," make sure you know what you're talking about.
Lastly, although I agree with you on some points about CM code, you should give them credit because your stuff is probably based on their stuff more then you lead others to believe; like nearly every other "dev group" out there. And by no means, am I some CM lover (I've had my quarrels with them), but you should give respect and credit to those who make what you do possible.
Click to expand...
Click to collapse
See Above.
drewX2 said:
I think you misunderstood what I said. First of all, I am speaking from *experience*. I have ported AOSP to devices without RELEASED proprietary binaries...
...How do I know? I've done it. I was the first to build CM for HTC DNA and both CM/AOSP for Oppo Find 5. Next time before you "completely disagree," make sure you know what you're talking about.
[/QUOTE
Great, hi-five to you, but before making bold assumptions...
http://www.xda-developers.com/android/aosp-jellybean-build-for-the-t-mobile-g2x/
drewX2 said:
...(CM) you should give them credit because your stuff is probably based on their stuff more then you lead others to believe; like nearly every other "dev group" out there. And by no means, am I some CM lover (I've had my quarrels with them),....
See Above.
[/QUOTE
I never suggested anything about CM, they are top-notch. I said we dont use their base code like "every other dev". Sorry you have had quarrels; and there is nothing "probably based off them" as I just told you our repo is straight AOSP & EB.
Likewise you should "know what you're talking about", prior to making assumptions and speculations.
^read above
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Im currently working on this as well...anyone have anymore success? Im currently fighting my way through compile errors...but I would love to be able to atleast get a bootable pure aosp from source...ill keep at it...but if anyone has gotten it yet please help speed up my process and enlighten me on what you did to compile a working aosp
Sent from my SAMSUNG-SGH-I337 using Tapatalk 2
I guess we all are I'm working on one too. Lots of research on correcting errors
Cm10.2 anyone??
Sent from my GT-I9505G using Tapatalk 2
deleted
Wrong post
I did it successfully with help of some external repos
forum.xda-developers.com/showthread.php?t=2397511