I plan to build Cyanogenmod 10 from source, however I have a few questions.
When compiling the kernel from HTC sources, I get two warnings along the line of "warning: (ARCH_MSM_KRAITMP && ARCH_MSM_CORTEX_A5)." I am assuming these are safe to ignore? Other than, it builds and completes fine.
I've never built from source any roms (and for that matter have only done minor programming some time ago), however I have an extensive experience in programming and want to give it a shot.
Is there any reason why it is not possible to build an unofficial port? Wouldn't having the kernel sources from HTC make the job easier? Anyone try this yet or have experience with porting to new devices?
I have next to no programming/hardware/software modding experience but I believe some devs are working on the RIL (radio interface layer) for this phone before they get a working CM10 on the DNA...
I could be completely wrong but just chiming in lol
You can probably build it and get it booting without too much hassle. But you won't have any connection whatsoever. That's where the ril comes in. But it hasn't been cracked yet, beck, idk if anyone's even working on it atm.
Sent from my HTC6435LVW using xda app-developers app
drewX2 said:
I plan to build Cyanogenmod 10 from source, however I have a few questions.
When compiling the kernel from HTC sources, I get two warnings along the line of "warning: (ARCH_MSM_KRAITMP && ARCH_MSM_CORTEX_A5)." I am assuming these are safe to ignore? Other than, it builds and completes fine.
I've never built from source any roms (and for that matter have only done minor programming some time ago), however I have an extensive experience in programming and want to give it a shot.
Is there any reason why it is not possible to build an unofficial port? Wouldn't having the kernel sources from HTC make the job easier? Anyone try this yet or have experience with porting to new devices?
Click to expand...
Click to collapse
You will probably get a couple errors during the build, nothing to worry about. If you get an error and the build stops then you know you have a problem.
Also, we have the kernel source from HTC. Building custom kernels is a necessary step before we can build CM, but it doesn't really make anything easier. Like Bigandrewgold said, the RIL is the most important missing link at this point.
I wish you the best on this project, and you have a great community here of people who can help you out.
I myself would love to test out CM on this beast, ril or not. It'd be nice to have a build ready that we could just drop a kernel into.
Sent from my HTC6435LVW using Tapatalk 2
Related
So am i the only one here that notices that there hasn't been an update for a ROM in about a month? What's been going on?
Not really. IHO is still alive and well. Some of the froyo roms are at end of life and are considered more or less finished (Harmonia and Bumblebee to name a couple).
Sent from my LG-VM670 using Tapatalk
I don't think it helped that the kernel site was hacked and has been down...?
We are all waiting for kernel.org to be back up, kinda hard to build without source.
Some hackers must sit around and think "Who can I piss off today? I know, most of the android dev community." Some hackers just suck.
Sent from my VM670 using XDA App
This explains a lot.. I've been waiting for an update on IHO for a while
Sent from my LG-VM670 using xda premium
Thanks for the information I had no idea kernel.org got hacked.
Sent from my LG-VM670 using Tapatalk
It is hard waiting for kernel.org to get back up, but I'm more than willing to wait it out patiently. We are talking about the basis to the entire Linux community here, not just Android. While we are pretty sure the hackers couldn't have gotten anything in that wouldn't be noticed due to the inherent nature of the repository system, it is prudent that they do such dilligent work checking everything out to be certain. Imagine if someone was able to insert malicious code at the basis of the kernel's distribution system, botnets that instantly compromise millions of computers, all user data compromised the moment you update your system, the imaginary horror stories are all too real possibilities.
Go outside, fix that garage door, paint that fence, or at least take down last year's xmas lights. Kernel.org will be back up soon enough, and we can all go back to worrying about which color looks best on our phones buttons.
@JerryScript:
I'm guessing you didn't get the codaurora repo patched into your cm7 build system like you mentioned you were going to try?
I bet it's murder to patch CAF source addresses into the repo manifest instead of kernel.org, huh?
bummer.
that blog link you posted over in the build-your-own-rom thread on AC worked great for codeaurora by itself, which I appreciate greatly since I was already working with that before kernel.org bit the big one. then I couldn't sync it for a while until you pointed me the way.
bigsupersquid said:
@JerryScript:
I'm guessing you didn't get the codaurora repo patched into your cm7 build system like you mentioned you were going to try?
I bet it's murder to patch CAF source addresses into the repo manifest instead of kernel.org, huh?
bummer.
that blog link you posted over in the build-your-own-rom thread on AC worked great for codeaurora by itself, which I appreciate greatly since I was already working with that before kernel.org bit the big one. then I couldn't sync it for a while until you pointed me the way.
Click to expand...
Click to collapse
Blarf told me that CAF was to much of a mess to rely on. I'm currently syncing using TI's omapzoom, will let you know if I get a successful build environment setup.
Edit-- There is an easier way than manually patching the mirror, just use the following:
Code:
$ repo init -u git://github.com/inferiorhumanorgans/android.git -b gingerbread --repo-url=git://git.omapzoom.org/tools/repo.git
Notice the --repo-url appended to the normal init line, that will do all the patch magic for you. All you have to do is change the remote.
Big thanks to Sanghee Kim for posting this:
https://groups.google.com/forum/#!topic/repo-discuss/r0wkGaloA5k
@jerryscript I would highly suggest making your own thread with the above information just to make sure all of the devs see. Might help them out a little
Sent from my LG-VM670 using Tapatalk
gannon5197 said:
@jerryscript I would highly suggest making your own thread with the above information just to make sure all of the devs see. Might help them out a little
Sent from my LG-VM670 using Tapatalk
Click to expand...
Click to collapse
I plan on it, as soon as I finish a successful compile.
Sorry I hijacked your thread, to answer your op, should have some new builds soon.
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.
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
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?
Hey guys, hoping anyone who finds this project interesting reads this.
I'm currently working on a tw kernel for the i9505, and have been doing some major backporting feature-wise to our device, including power management (autosuspend, faux's powersuspend, state notifier, all working!), cpu/scheduling infrastructure, all the fun little tweaks, etc.
I'm wondering if anyone wants to work on it with me? Making kernels is fun, but I'd love to have fellow geeks to discuss/work on stuff with.
Eventually I'd like to look into reasonably building an upstreamed kernel with full device tree support, (min 3.10) as mainline is finally adding 8064/8960 dtb support. Only issues there is that support for the board skipped kernel versions 3.4-4.1, so some 3.1x hacking would come into play, as well as the unique qualities of jfltexx's board that are samsung specific (again more hacking). Still, it's more of a head start than it would be from scratch. Also we'd have to use of_compat given that little kernel bootloader building is (probably) out of the question for this device.
Anyway, anyone who is interested feel free to get a hold of me, and check out https://github.com/robcore/machinex
Cheers
Rob
i do
i although i am working on CM roms
optimized cm13.0 is mine
optimzied cm14.0 too
now releasing optimized cm14.1
if u care to come with me,tell me
side said:
i do
i although i am working on CM roms
optimized cm13.0 is mine
optimzied cm14.0 too
now releasing optimized cm14.1
if u care to come with me,tell me
Click to expand...
Click to collapse
Hehe I was just chatting with someone today regarding how I'd be more than happy to work on a CM kernel, but have no bloody clue regarding the specific needs I'd have to consider for cm. I'm more than happy to work with you though, so long as you are able to point me in the right direction sometimes and are willing to be patient with my *limited* git skills (I've had a couple blokes help me with cherry-picking instead of manual patching, but haven't attempted yet because last time I broke my repo :silly: ). I'm more than happy to "branch" out, pun intended. Do you have telegram? I'm @robcore
robcore said:
Hehe I was just chatting with someone today regarding how I'd be more than happy to work on a CM kernel, but have no bloody clue regarding the specific needs I'd have to consider for cm. I'm more than happy to work with you though, so long as you are able to point me in the right direction sometimes and are willing to be patient with my *limited* git skills (I've had a couple blokes help me with cherry-picking instead of manual patching, but haven't attempted yet because last time I broke my repo :silly: ). I'm more than happy to "branch" out, pun intended. Do you have telegram? I'm @robcore
Click to expand...
Click to collapse
i just saw that reply.i dont know how i lost it. u better send me a pm