I know I have just asked some rather Simple Kernel Questions and honestly as stated as always worked as part of a dev team and was never the Kernel Guy but with that said have always wanted to build an AOSP Rom based on the Code Aurora source. Not caf like CM or anything with all kinds of features and what not but just pure AOSP. Thought I would ask if anyone else would be down.
The Rom would be pure AOSP based on Code Aurora repository’s only. Have always wanted to look into doing this and looking into how to go about it.
Ok, first off, some useful descriptions;
AOSP: The source code provided by Google. This is directly buildable for Nexus 6 just by following the instructions.
CAF: The source code provided by Qualcomm, which typically involves *some* degree of feature addition, but mostly HARDWARE bringup.
The odd thing about the relationship between AOSP and CAF, is that they are both each other's upstream. I think I would classify CAF as being somewhat more of "experimental" code.
CM: a complete and utter MESS. It takes bits from here, bits from there, and throws in a jumble of other bits... none of which really work well together or were intended to be merged in that way.
Basically, CM is not so much a build of CAF as they pull in certain *parts* of CAF. So if you did a build of PURE CAF, it would much more closely resemble a build of AOSP.
Now is CAF buildable for Shamu? Hmm, sortof.... maybe. They do pull in AOSP, but I don't think they actually work with Nexus devices so much as their own internal development devices, and certain specialty "dev" devices like Dragonboard 410c. What that means, is that you will probably want to start off with a *generic* apq8084 manifest from https://www.codeaurora.org/xwiki/bin/QAEP/ under the "release" branch. You will then need to mess around with the blobs and kernel, add a shamu device tree, etc., and what you end up with at the end, will strongly resemble a pure AOSP build, but probably have a few things broken or unstable.
IMO: For something like Shamu, you don't really do a pure CAF build, since google has already selected and stabilized the appropriate parts of CAF for you. But if you see some new or not-included FEATURE in CAF, then you consider pulling that specifically into an otherwise AOSP build.
doitright said:
*lots of text*.
Click to expand...
Click to collapse
It's funny... I've had people argue this with me in the past few weeks...
This is pretty much exactly my understanding of it as well.
The biggest difference between AOSP/GoogleSource & CAF for me, is that CAF is much more lively... typically. Google puts out source on their Public Repos, but it always reflects their latest release. I'm sure they have internal repos that are more lively... But the public ones are usually stagnant until a new release.
Of Course, stock roms (even for us) include a lot of vendor blobs that AOSP don't.
Yoinx said:
It's funny... I've had people argue this with me in the past few weeks...
This is pretty much exactly my understanding of it as well.
The biggest difference between AOSP/GoogleSource & CAF for me, is that CAF is much more lively... typically. Google puts out source on their Public Repos, but it always reflects their latest release. I'm sure they have internal repos that are more lively... But the public ones are usually stagnant until a new release.
Click to expand...
Click to collapse
Yep, that is pretty much why I used the term "experimental".
Of Course, stock roms (even for us) include a lot of vendor blobs that AOSP don't.
Click to expand...
Click to collapse
You do know that google provides the vendor blob archives, right? That is, the parts required to make the AOSP build fully functional on Nexus hardware. Those vendor blobs don't include any of the googly bits in the userspace layer (i.e., gapps).
Related
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.
I'm sure I'm not the first developer to ask this question, so at the risk of possible embarrassment I pose this question to the development community as a way for myself and others to learn:
When we build AOSP projects we often do based on the repos from that project. But in Samsung's OSRC releases you often get 2 packages: kernel source and a "platform" package. In there is what Samsung "says" is needed to build AOSP for that given device. For example, I often see bluetooth and audio source in there.
So here's the question....
Given the issues we're seeing in i9505 variants for Bluetooth and headphone call audio, why do we not try using this source for testing purposes? Sure, it may not be the newest but if it works where we are currently having issues; couldn't the differences be merged and hopefully resolve the issue?
Obviously Samsung's solution of just "dropping" the source on top of stuff already being used doesn't make sense. But I can't believe I'm the first to ask and there has to be a reason why. Hopefully some maintainers can shed some light and by doing so, help newer devs (like me) understand the background behind it.
Thanks!
garwynn said:
I'm sure I'm not the first developer to ask this question, so at the risk of possible embarrassment I pose this question to the development community as a way for myself and others to learn:
When we build AOSP projects we often do based on the repos from that project. But in Samsung's OSRC releases you often get 2 packages: kernel source and a "platform" package. In there is what Samsung "says" is needed to build AOSP for that given device. For example, I often see bluetooth and audio source in there.
So here's the question....
Given the issues we're seeing in i9505 variants for Bluetooth and headphone call audio, why do we not try using this source for testing purposes? Sure, it may not be the newest but if it works where we are currently having issues; couldn't the differences be merged and hopefully resolve the issue?
Obviously Samsung's solution of just "dropping" the source on top of stuff already being used doesn't make sense. But I can't believe I'm the first to ask and there has to be a reason why. Hopefully some maintainers can shed some light and by doing so, help newer devs (like me) understand the background behind it.
Thanks!
Click to expand...
Click to collapse
The stuff in platform isn't what is needed for AOSP - it is (with rare exceptions) only GPL-licensed stuff Samsung is legally obligated to release.
Occasionally little bits and pieces of it are useful (like a single GS2 or GS3 release that included libsecril-client source code), but usually not.
For example, the BT stack in all GS1 platform releases was useless for AOSP, because it was Broadcom's hacked-up version that had dependencies on a proprietary binary (I forget its name - they got around GPL by making it a separate program that communicated using sockets with the rest of the BT stack.)
All of the BT/headphone problems with Snapdragon-based GS4s are, as I understand it, issues with libcsd-client (same library that was troublesome for Note2 and CM until someone ran libcsd-client through Hex-Rays Decompile to see what Samsung mangled...)
It seems like OEMs have a bad habit of hacking up libcsd-client in undocumented ways - LOTS of Qcom devices have had miscellaneous weirdness stemming from libcsd-client lately.
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
So i'm a bit confused. Which builds are better for fireball? The official cyanogen nightly or the unofficial mdm builds? I can't post in the offical dev post for cyanogen so i have to post here.
Right now i'm running the latest nightly. All seems to be be pretty stable. Just missing 16:9 for the camera, and once in a while while i'm running with my nikeplus app and the google music playing, if i hit the power button to turn off the screen it resets the entire device.
Anyways, i can't tell which builds are better / ahead of the others?
Sorry i know i posted this in another forum, but it was the wrong forum.
danjfoley said:
So i'm a bit confused. Which builds are better for fireball? The official cyanogen nightly or the unofficial mdm builds? I can't post in the offical dev post for cyanogen so i have to post here.
Right now i'm running the latest nightly. All seems to be be pretty stable. Just missing 16:9 for the camera, and once in a while while i'm running with my nikeplus app and the google music playing, if i hit the power button to turn off the screen it resets the entire device.
Anyways, i can't tell which builds are better / ahead of the others?
Sorry i know i posted this in another forum, but it was the wrong forum.
Click to expand...
Click to collapse
I use MDM builds because I have the flicker issue from the cynagen 3.4 kernel. I don't think I've had any random reboots on the MDM like I did with the cyanogen nightlies.
Why then are the mdm releases.. or the guy behind the mdm releases, not working on the official releases? I mean why is his hard work not going into the official releases?
I feel like if i switch to mdm i'm going to miss fixes in the official nightlys.. as it's just one guy working on it.
Just doesn't make sense. the official releases are open sourced at git hub right? So why isn't the mdm guy working on the official releases?
danjfoley said:
Why then are the mdm releases.. or the guy behind the mdm releases, not working on the official releases? I mean why is his hard work not going into the official releases?
I feel like if i switch to mdm i'm going to miss fixes in the official nightlys.. as it's just one guy working on it.
Just doesn't make sense. the official releases are open sourced at git hub right? So why isn't the mdm guy working on the official releases?
Click to expand...
Click to collapse
@mdmower is working on official releases. instead of merging patches that might cripple the officials he is doing "beta" test outside of it. hence why he's always asking for feed back.
once he gets enough feedback on the mdm builds he submits a patch to cm and it gets merged into source. ^_^
i would go with the mdm5 build because it has a working camera focus but once he merges the RIL commit i will be going back because i like the stability of the officials minus the RIL hickup i had. but everyone is different and will react differently.
where did you get the 3.4 kernel?
Sum Dumb Guy said:
I use MDM builds because I have the flicker issue from the cynagen 3.4 kernel. I don't think I've had any random reboots on the MDM like I did with the cyanogen nightlies.
Click to expand...
Click to collapse
where did you get the 3.4 kernel?
synisterwolf said:
@mdmower is working on official releases. instead of merging patches that might cripple the officials he is doing "beta" test outside of it. hence why he's always asking for feed back.
once he gets enough feedback on the mdm builds he submits a patch to cm and it gets merged into source. ^_^
i would go with the mdm5 build because it has a working camera focus but once he merges the RIL commit i will be going back because i like the stability of the officials minus the RIL hickup i had. but everyone is different and will react differently.
Click to expand...
Click to collapse
This is mostly right, just couple clarifications:
mdm releases exist because CyanogenMod cannot publish releases that include a certain proprietary camera file. They are based on the latest stable CyanogenMod release (10.1.2) with a few tweaks that improve stability. Typically, these changes are backports from nightlies. In my opinion, these are the most functional CyanogenMod releases to date. Unfortunately, the kernel in use by these releases had to be dropped in order to prevent legal repercussions to CyanogenMod from closed-minded manufacturers.
I am actively working on the official nightlies. Unfortunately, HTC has not released kernel source for this phone that is meant to work with jellybean. Furthermore, hardware support (for every phone out there) still relies on closed-source manufacturer drivers/blobs, and this phone hasn't seen a jellybean release yet. Long story short, there's stuff that just doesn't work because of lack of jellybean-compatible kernel/firmware/drivers from HTC.
mdmower said:
This is mostly right, just couple clarifications:
mdm releases exist because CyanogenMod cannot publish releases that include a certain proprietary camera file. They are based on the latest stable CyanogenMod release (10.1.2) with a few tweaks that improve stability. Typically, these changes are backports from nightlies. In my opinion, these are the most functional CyanogenMod releases to date. Unfortunately, the kernel in use by these releases had to be dropped in order to prevent legal repercussions to CyanogenMod from closed-minded manufacturers.
I am actively working on the official nightlies. Unfortunately, HTC has not released kernel source for this phone that is meant to work with jellybean. Furthermore, hardware support (for every phone out there) still relies on closed-source manufacturer drivers/blobs, and this phone hasn't seen a jellybean release yet. Long story short, there's stuff that just doesn't work because of lack of jellybean-compatible kernel/firmware/drivers from HTC.
Click to expand...
Click to collapse
and thats why i like the XDA page system. ^_^ straight from the source ladies and gentlemen. thank you for clearing that up.
bad_christian said:
where did you get the 3.4 kernel?
Click to expand...
Click to collapse
3.4 are part of the official nightly releases. MDM uses 3.0.xx Kernels that are more stable for my phone.
I know this is yesterday's news but I felt compelled to post this and get other users input on this topic.
http://www.cyanogenmod.org/blog/releases-11-12-final
What I don't understand is Cyanogen's priorities when it comes to which devices get 11, 12 or 12.1. I completely understand about phasing out CM11/KitKat as that is now a rather "old" version of android. However what I don't understand is why a device as new/old as ours (Aug 2013 is not THAT old) is stuck on CM12 (and now a final Snapshot build as of 6/25)? I mean, the Galaxy S3 is even getting 12.1 builds. I'm wondering if its because that was a far more popular device than the G2 was?
Just wanted to put this out there and see what other people think and find out what they're running currently on their G2 variant. I own the US T-Mobile D801 variant and do NOT want to run stock (LG) Lollipop since my device tends to run extremely HOT on it. I know not everyone was complaining about their G2 overheating on stock LP but I notice a considerable difference running CM12.
So, how do you guys feel about this? Do you even care or what?
t3chn0s1s said:
I know this is yesterday's news but I felt compelled to post this and get other users input on this topic.
http://www.cyanogenmod.org/blog/releases-11-12-final
What I don't understand is Cyanogen's priorities when it comes to which devices get 11, 12 or 12.1. I completely understand about phasing out CM11/KitKat as that is now a rather "old" version of android. However what I don't understand is why a device as new/old as ours (Aug 2013 is not THAT old) is stuck on CM12 (and now a final Snapshot build as of 6/25)? I mean, the Galaxy S3 is even getting 12.1 builds. I'm wondering if its because that was a far more popular device than the G2 was?
Just wanted to put this out there and see what other people think and find out what they're running currently on their G2 variant. I own the US T-Mobile D801 variant and do NOT want to run stock (LG) Lollipop since my device tends to run extremely HOT on it. I know not everyone was complaining about their G2 overheating on stock LP but I notice a considerable difference running CM12.
So, how do you guys feel about this? Do you even care or what?
Click to expand...
Click to collapse
We haven't had nightlies for a while now. What you see as nightlies aren't really worthwhile builds, they didn't have any device or kernel fixes for the g2.
A new 11 build is coming probably because half the android userbase relies on kitkat at the moment.
As for the s3, it's not getting CM12 nor 12.1, not the international version at the least. Archi is maintaining an unofficial version, but it still carries the bugs from 10.0/10.1.
Lastly, this is the commit that requires to be merged in order for the builds to even be considered started:
http://review.cyanogenmod.org/#/c/93181/
Without it, nothing CAF related can be merged, and as such, no CM12.1 builds can be had for our device. I believe the reason it's not merged because not all of the variants have a lollipop release, if they ever will get one. Also the whole bootstack/amount of users who don't reed is astonishingly dangerous to handle, so rashed simply preferred to skip building for now.
Finally, it's not that popular of a device. It's a nexus without being a nexus with a locked bootloader, which is a pain in the ass and not too many maintainers have it left (they either went with G3 or skipped LG entirely, as did a whole bunch from the exynos team back in the day).
t3chn0s1s said:
I saw you responded to my post about CM12 nightlies not continuing for the G2. Wanted to ask you (since you didn't mention) what 5.1 (CAF source) ROM you're running? What would you suggest for a stable AOSP ROM that has device/kernel specific updates for our G2s?
Click to expand...
Click to collapse
Why not reply to me in this thread then?
I'm running official euphoria builds. Any caf roms run fine. They are all based on the same LG-devs CAF device source + kernel source. Some roms have specific tweaks, but as far as functionality, they all work the same way (ie: if bluetooth deep sleep is broken, it's most likely broken in every rom).
Choristav said:
Why not reply to me in this thread then?
I'm running official euphoria builds. Any caf roms run fine. They are all based on the same LG-devs CAF device source + kernel source. Some roms have specific tweaks, but as far as functionality, they all work the same way (ie: if bluetooth deep sleep is broken, it's most likely broken in every rom).
Click to expand...
Click to collapse
Sorry - was on my phone when I saw your replies and it was just easier for me to respond in the other thread.
Anyways.. thanks for the info. I've done some research and I'm a bit more informed about CAF and what it means to device specific sources, ROMs, etc. Are you just using the stock Euphoria kernel or something else?
On this forum @varund7726 builds his rather excellent ResurrectionRom from the latest CM code release. I suggest you use that. For the D803, @zr239 has beaten all odds including LG not releasing CAF code, to build a fully functional pure CM 12.1 ROM that closely tracks official CM repos.
Lg G2 has it pretty good !
@Choristav
I wanted to clarify something you said in your initial response to my OP. You said the S3 wasn't going to get CM12 or 12.1 but when I navigate to the CM downloads page for ANY S3 variant - they ALL have CM12.1 nightlies still being generated. What exactly did you mean?
t3chn0s1s said:
@Choristav
I wanted to clarify something you said in your initial response to my OP. You said the S3 wasn't going to get CM12 or 12.1 but when I navigate to the CM downloads page for ANY S3 variant - they ALL have CM12.1 nightlies still being generated. What exactly did you mean?
Click to expand...
Click to collapse
I checked, you are right, several of the qualcomm variants have cyanogenmod support. This means that they have active maintainers, but they also don't have to deal with locked bootloader crap, which is why the bump commit is so important for our device.
I only mentioned the international version, which support was dropped because it had a lot of issues thanks to its closed source exynos processor (it requires extra work, and some stuff doesn't end up working anyway).
Not really much to say, the commit is already in CM's gerrit, it's just waiting for review. Maybe it's a CTS-side issue?
Aside from that, being a maintainer doesn't really require much, just effort and presence. It's not an easy task, I'm just saying anyone can apply to be a maintainer and get nighties rolling for a device you might not even have heard of.
@Rashed97 is the man for our G2 when it comes to CM. Dont mind nightlies as long as Rashed is around
Note: he is currently busy with the One M9 but we will hopefully see some cool stuff from him in the future.
Not really a big deal, last I remember those nightlies were still using outdated jellybean components. I wouldn't use them, I would use something on the G2 forums like Rashed97 builds like someone else said.
I don't think that the availability of nightlies has to do with the device itself so much as it has to do with someone maintaining the g2 and building roms, so nightlies could come back at any time if someone steps up and does it.
Ploxorz said:
Not really a big deal, last I remember those nightlies were still using outdated jellybean components. I wouldn't use them, I would use something on the G2 forums like Rashed97 builds like someone else said.
I don't think that the availability of nightlies has to do with the device itself so much as it has to do with someone maintaining the g2 and building roms, so nightlies could come back at any time if someone steps up and does it.
Click to expand...
Click to collapse
And it appears you're correct as there is another nightly build up with today's date. I apparently posted this thread prematurely.
Guys I wouldnt worry to much about CM, its not like they are the only (or even best) option in the forums. If you guys want development then dig in and make some for it.
zelendel said:
Guys I wouldnt worry to much about CM, its not like they are the only (or even best) option in the forums. If you guys want development then dig in and make some for it.
Click to expand...
Click to collapse
You are absolutely right. I had no idea until I posted this thread that CM nightlies did not contain any device specific updates. I honestly NEVER used to like CM at all. I honestly hated it... until owning a OnePlus One. I originally had the G2 right when it came out in 2013 and sold it off long ago & moved on to better devices - but when my OPO got stolen about 2 months back or so - I had to find a relatively cheap, but decent device and the G2 was the best bang for the buck (5.2" display, quick charge 2.0, 3000 mAh battery) and no other phones in 2013 came close to the specs the G2 had at the time.
So, now that I know CM is basically a sh*t ROM for this device I'll be moving on to a ROM that is compiled using CAF sources. Thanks everyone for your input!
Somehow doesn't look too good so far:
https://jira.cyanogenmod.org/browse/CYAN-6556
But why oh why?
The LG G2 still is such a modern and powerful device. It might be almost two years "old", but it's way better than a lot of other current devices.
I am using AICP on my g2. It is based on CM(5.1.1).
What's the best place to follow updates / changes to the CAF stuff?
I know there's a handful of ROMs based on CAF sources, I'm not too interested in the changelogs of those ROMs, more following the progress of CAF before it eventually all gets merged into CM12.1.
Is this it? https://github.com/lg-devs/android_device_lge_g2-common/commits/cm-12.1-caf
seanp25 said:
What's the best place to follow updates / changes to the CAF stuff?
I know there's a handful of ROMs based on CAF sources, I'm not too interested in the changelogs of those ROMs, more following the progress of CAF before it eventually all gets merged into CM12.1.
Is this it? https://github.com/lg-devs/android_device_lge_g2-common/commits/cm-12.1-caf
Click to expand...
Click to collapse
I would watch the Code Aurora forums where CAF comes from.
zelendel said:
I would watch the Code Aurora forums where CAF comes from.
Click to expand...
Click to collapse
It's better to watch public activity on Rashed97's github. He is CM maintainer for LG G2 and he brought up CAF sources for our devices.
adamz667 said:
It's better to watch public activity on Rashed97's github. He is CM maintainer for LG G2 and he brought up CAF sources for our devices.
Click to expand...
Click to collapse
No. It's far better to watch the main code base. Cm messes too much up by not testing code before merging.
zelendel said:
No. It's far better to watch the main code base. Cm messes too much up by not testing code before merging.
Click to expand...
Click to collapse
Okay, but @seanp25 probably want to follow source changes for our device, not common CAF source.
Just saw this:
Çetin ÇÖNE wrote on Jul 26 11:18 AM:
Why there is no nighlies it's really stable. Merge it please
Seth Shelnutt wrote on Jul 26 1:26 PM:
There are no nightlies because SELinux is not enabled. Sensors break with it enabled and I don't have time to address it yet.
Click to expand...
Click to collapse
Source:
http://review.cyanogenmod.org/#/c/103673/
Some days after that there came this:
http://review.cyanogenmod.org/#/c/103674/
So maybe there soon will be 12.1 nightlies?