FXP vs CM? - Xperia Z General

Not really sure where this belongs, so Mods, please feel free to move it.
Given all the changes within CyanogenMod recently, and the formation of Cyanogen as a business, what's likely to happen to the FXP team? I know Kali has already said he won't develop CM any more.
Everyone has their own views on the politics of the situation, and this isn't really about that.
Just saying, guys, that if you happened to leave CM and develop your own AOSP-based ROM, I'm sure you'd have a lot of followers

Probably OmniRom.
http://forum.xda-developers.com/forumdisplay.php?f=2601
http://forum.xda-developers.com/showthread.php?p=46423532#post46423532
Apparently the XZ is up and running.

I'm using cm10.1.3 (stable version), with one modification (softkey decreases for 32DP, has this mod here in the forum) and I am fully satisfied.
No bug's, clean, smooth and beautiful automony battery.
I recommend.

Ooh Omnirom looks interesting,
Time to sync sources while I'm at work...
Sent from my C6603 using Tapatalk

fards said:
Ooh Omnirom looks interesting,
Time to sync sources while I'm at work...
Sent from my C6603 using Tapatalk
Click to expand...
Click to collapse
patiently waiting for a yuga release..time for something fresh.

ckyy said:
patiently waiting for a yuga release..time for something fresh.
Click to expand...
Click to collapse
I think there'll be official releases out very soon, but I'll have a look at it later on when I get chance and see how it builds and runs.
No point trying to build on my machine at work, it's steamdriven!
If the build works I'll post it . Surprised @pulser_g2 hasn't posted one already

Well @fards if it runs well....it'd be nice if you could put a build up for us to have a sneak peak
Sent from my C6603 using Tapatalk

Now I've had a chance to take a look at it (not built anything I'm still looking at device trees etc) I'm a bit underwhelmed.
There's more CM and less AOSP than I'd like, lots more CM.
Going to try merging Pabx brilliant Aosp with this too see if I can get anywhere.
Don't expect anything quick, if I can motivate myself to churn through it!

No rush @fards. Not exactly an obligation to do it. Thanks again.
Sent from my C6603 using Tapatalk

tbh at the moment the entire project just appears to be a fork of CM.
far too much of it for my tastes.
I'd wish they'd started with a pure aosp base.

fards said:
tbh at the moment the entire project just appears to be a fork of CM.
far too much of it for my tastes.
I'd wish they'd started with a pure aosp base.
Click to expand...
Click to collapse
Oh dear. Back to the usual aosp rom then

@ fards
omnirom started from pure AOSP as compare to cyanogemod
---------- Post added at 12:42 PM ---------- Previous post was at 12:40 PM ----------
@ fards
omnirom started from pure AOSP as compare to cyanogemod

xZain69 said:
@ fards
omnirom started from pure AOSP as compare to cyanogemod
---------- Post added at 12:42 PM ---------- Previous post was at 12:40 PM ----------
@ fards
omnirom started from pure AOSP as compare to cyanogemod
Click to expand...
Click to collapse
I suggest you go take a proper look at the github, then come back and say "sorry they are using mostly cm".
The apq kernel is the cm one(didn't look at the others close enough to care). Other device trees are cm. The git structure is cm.
www.github.com/omnirom
https://github.com/omnirom/android_kernel_sony_apq8064
Code:
defconfigs: debranding
We're not a part of cyanogenmod any more. Also to avoid anyone else
having to do this, let's make the names generic to facilitate cross-
project
Change-Id: I89b6626636d568b36b9979272c6099fd074840e3
That changes the name only of the cm defconfigs. THESE are Not aosp, they are cm based.
Ergo it's a cm fork.
https://github.com/omnirom/android_device_sony_qcom-common
Code:
README.md
Copyright 2013 - The CyanogenMod Project
android_device_sony_qcom-common
Sent from my C6603 using Tapatalk

fards said:
I suggest you go take a proper look at the github, then come back and say "sorry they are using mostly cm".
The apq kernel is the cm one(didn't look at the others close enough to care). Other device trees are cm. The git structure is cm.
www.github.com/omnirom
https://github.com/omnirom/android_kernel_sony_apq8064
Code:
defconfigs: debranding
We're not a part of cyanogenmod any more. Also to avoid anyone else
having to do this, let's make the names generic to facilitate cross-
project
Change-Id: I89b6626636d568b36b9979272c6099fd074840e3
That changes the name only of the cm defconfigs. THESE are Not aosp, they are cm based.
Ergo it's a cm fork.
https://github.com/omnirom/android_device_sony_qcom-common
Code:
README.md
Copyright 2013 - The CyanogenMod Project
android_device_sony_qcom-common
Sent from my C6603 using Tapatalk
Click to expand...
Click to collapse
@fards : Have a word with yourself mate ;
The git structure is the defacto standard as used by every rom who hosts on github , PA/Omni/CM.
You cannot have sub directories in your user namespace on github so you cannot represent things in the same way as you would with your own git server with a gitweb/gtiles frontend
The device trees are ported from cm for convience the rest of the project uses repo's forked from AOSP or the AOSP it's self
So instead of scanning one repo's commit messages and making a conclusion. I would suggest you read the default manifest as well to see where the sources are pulled from
https://github.com/omnirom/android/blob/android-4.3/default.xml

fards said:
I suggest you go take a proper look at the github, then come back and say "sorry they are using mostly cm".
The apq kernel is the cm one(didn't look at the others close enough to care). Other device trees are cm. The git structure is cm.
www.github.com/omnirom
https://github.com/omnirom/android_kernel_sony_apq8064
Code:
defconfigs: debranding
We're not a part of cyanogenmod any more. Also to avoid anyone else
having to do this, let's make the names generic to facilitate cross-
project
Change-Id: I89b6626636d568b36b9979272c6099fd074840e3
That changes the name only of the cm defconfigs. THESE are Not aosp, they are cm based.
Ergo it's a cm fork.
https://github.com/omnirom/android_device_sony_qcom-common
Code:
README.md
Copyright 2013 - The CyanogenMod Project
android_device_sony_qcom-common
Sent from my C6603 using Tapatalk
Click to expand...
Click to collapse
Andrew Dodd (Entropy512) has been one of the major Sony contributor to CyanogenMod, so were a few people that are helping us on Omni. Just because one device tree has been taken off an existing CyanogenMod repository doesn't mean we are a CM fork. It would be shooting ourselves in the foot to start device trees from the ground up again.
Besides some device trees, everything else has been up from AOSP. Therefore, we're not a CM fork.

Related

Ice Cream Source Build?

Hi,
i know that the build would be slow as hell but has anyone compiled ICS for the G1? just for trying it ?
i would like to try it myself but i have no clue on how and from hat i`ve heard my computer would take ages to build it
It's done for droid eris, it can be ported to G1.
http://forum.xda-developers.com/showthread.php?t=1352170
Porting would be inefficient when it can be built from source.
Unfortunately I can't do neither
Sent from my GT-I9100 using XDA App
Ice Cream Sandwich Build Help
As soon as the source was released I was thinking about trying to build it for "old reliable" (my nickname for my old G1). I know it would be slow as mud but I still want to give it a try. Problem is I've never compiled the source of Android before so I would be going in blind. I've read the info at source.android.com so I have somewhere to start. If anyone has any other guides/tutorials on how to build Android for a device then I would be really appreciative. I'm a Computer Science major so don't be afraid to throw a little code at me either. I'll include the details of my phone below in case anyone needs it.
HTC Dream
SPL: HBOOT-1.33.2005 (DangerSPL)
Radio: 2.22.19.261
OS: CyanogenMod 6.1 (Android 2.2.1)
You can have a look at Terry' ezGingerbread thread. Here he explains what to do to compile his ezGingerbread from the sources. Principally compiling ICS is the same, but you need to exchange / modify the manifest to your needs.
Sent from my Gingerbread on Dream using XDA App
Thanks, I looked it up and it was really helpful. Just a couple of quick questions. Do you know how far from stock ezGingerbread is? What do you mean when you say manifest? When people port a new version to a new device how is it normally done?
Thanks for your help. If I manage to get anything useful I'll be sure to share it here first.
Sent from my DROID3 using XDA App
hyperspace290 said:
Thanks, I looked it up and it was really helpful. Just a couple of quick questions. Do you know how far from stock ezGingerbread is? What do you mean when you say manifest? When people port a new version to a new device how is it normally done?
Thanks for your help. If I manage to get anything useful I'll be sure to share it here first.
Sent from my DROID3 using XDA App
Click to expand...
Click to collapse
It's almost stock, but there are some projects from CM included and some he cloned from CM or from other sites and manages them by himself. Details you can see it in his manifest.xml located in the .repo directory. The manifest defines, what projects are to be included and what branch you want to use for these projects.
You will not want my manifest for ICS (at least unless I make an ICS branch myself)
The reason is you will want to use the ICS git repos and not the GB git repos (original or cloned by me)
That said if you are new to building an android rom look at the structure using ezgb some, and build ezgb, then when you understand the structure clone ICS from aosp (see info on source.android.com) and create your own manifest from that including cloned git repos you need from ezgb with any addtl modifications required.
The first thing is:
* Git is the source control for all parts of android, however many (well over 200) git repos are used in ICS
* Repo is a tool (python script with plugins pulled from its own git repo) for maintaining all of the git repos used in an android build, and creating the true tree of repos needed for the work directoy.
* Manifest is a special git repository with default.xml (and sometimes other manifest xmls) used by the repo script to find all the projects other git repositories, as well as what branch/commit to checkout to the work directory.
Thanks for the advice guys. Glad to see the little G1 is still getting some love. I think I'll start by building ezGingerbread to get the handle on the build process for Android and at least get up to 2.3.
If anyone knows what kinds of modifications are normally needed for a port like this then I would appreciate the help. Is it normally just editing some config files or would I have to dive into the code? Thanks again.
Sent from my DROID3 using XDA App
Looks like someone has beaten me to the punch. Anyone interested shout go have a look at this thread: http://forum.xda-developers.com/showthread.php?p=19648827
not exactly.
that is a port from a source-build for the hero
but very close
looks like the dev is trying to make a source build for the dream.
you could contact him so you can work together
Really get the cm9 source, pull forward the dream/sapphire device trees from cm7 (or firerats port of that) and it ought to be alright.
There seems little in the way of true cm bits at current (sure to change soon) but most of the hardware backwards compatibility patches are alredy in cm9 from the looks of it.. for all I know this is a cm9 build since aosp has no hero device tree out of box.
I was going to reply to that thread but since I'm still considered new I can't post to development threads. I guess I will PM the dev later to let him know I'm interested in helping him out.
Why would you build for another device if the dream has built into AOSP? Doesn't make a whole lot of sense to me unless they flat out took out the board file in ICS but you could easily put it back by pulling it from an earlier revision.
Sent from my DROID3 using XDA App

[ROM] [FIND5] [4.2.2] [cfX-Toolchain 4.8.y+] codefireXperiment

This new Android distribution treats development differently than any other.
CLICK HERE FOR THE ROM, THREAD, CHANGELOG, AND DISCUSSION.
A post detailing our team and new developers from TeamEOS can be found in the OP linked.
ntroducing codefireXperiment for your device! This OP is going to stay slim and bloat free, just like codefireXperiment. No marketing buzzwords either. We take such confidence in the speed and performance of this distribution, we challenge you to find a faster and more stable one!
Here's a bit of info you may want on this project for how we do things differently:
No features you don't need which slow the device down, or put your data at risk of being stolen. If you want to give it away, it should be your decision.
A fast and clean install with no UX decisions made for you. You make the ROM whatever you would like.
A team constantly exploring totally new feature sets and optimizations geared toward you, the user
We utilize a plethora of optimizations in a build system unlike any other:
Each build has a toolchain built for your device at the time of build. No more generic toolchain android builds.
Consistently updated upstream toolchain module source with our custom backports, fixes, and optimizations applied in a patch at build time.
Fully built utilizing Link Time Optimization (another custom ROM first). Feel free to google this one a bit to get an idea of the performance gain.
Many repositories have code fixes, cleanups, and many minor optimizations which are too generous to even speak of here.
Optimizations are toggled on and off based on device for the best experience we can acheive for your device without sacrificing any stability
Many Qcom optimizations and AOSP master (upstream) optimizations and fixes using device specifications to determine usage.
Fully built utilizing strict aliasing and isognu++11 mode.
Full "-O3" build. To those who don't know, this is the highest "optimization level" available in gcc that sets many other flags.
Enjoy, and thank you for choosing codefireXperiment
XDA:DevDB Information
[ROM] [AOSP] [4.2.2] [cfX-Toolchain 4.8.y+] codefireXperiment, ROM for the Oppo Find 5
Contributors
anders3408
ROM OS Version: 4.2.x Jelly Bean
ROM Kernel: Linux 3.4.x
Based On: AOSP
Version Information
Status: No Longer Updated
Current Stable Version: JDQ39E-20130
Stable Release Date: 2013-08-11
Created 2013-09-04
Last Updated 2014-08-18
Nice team you assembled there, looking forward to trying it out. openpdroid patches failed for me, oh well, gotta get more experience with xprivacy anyway.
BTW, didn't see it on your site so far, featurelist somewhere(espacially in terms of the kernel in use)?
any screenshot
S.D.Richards said:
BTW, didn't see it on your site so far, featurelist somewhere(espacially in terms of the kernel in use)?
Click to expand...
Click to collapse
look at the Github link to the kernel source
Sent from my HTC One X+ using xda app-developers app
maxwen said:
look at the Github link to the kernel source
Sent from my HTC One X+ using xda app-developers app
Click to expand...
Click to collapse
https://github.com/codefireXperimen.../arch/arm/configs/cyanogenmod_find5_defconfig
Hard looking through that looking for pieces if you don't know the specific CONFIG_xxx name.
Anyway, in a quick scroll through, I fell over some enabled (=y) USB OTG stuff - I was under the impression the device doesn't support it?
Nightly is blazing fast. Quickest boot times ever. Even the first boot was super fast.
Sent from my Find 5 using xda app-developers app
Sorry to ask, I probably missed it somewhere... is this AOSP based, or other? Max's kernel is going on this bad boy if I try it... unless... it's already in there
no idea what this is, but i will flash it and take a look
Pure aosp based. For now not as many features as the other codefirex, but things are being added. Kernel is cm based with a few changes from maxwen and faux123, thanks both. Credits thread will come up.
Sent from my Find 5 using XDA Premium HD app
charlatan01 said:
Sorry to ask, I probably missed it somewhere... is this AOSP based, or other? Max's kernel is going on this bad boy if I try it... unless... it's already in there
Click to expand...
Click to collapse
Not tested maxwen kernel on it but you should be ready to reflash then, not totally sure it will work. Early tests did bootloop on maxwen kernels.
Sent from my Find 5 using XDA Premium HD app
anders3408 said:
Not tested maxwen kernel on it but you should be ready to reflash then, not totally sure it will work. Early tests did bootloop on maxwen kernels.
Sent from my Find 5 using XDA Premium HD app
Click to expand...
Click to collapse
Thanks... I will hold off on flashing his kernel for the time being. It would be nice to get that working if possible.
charlatan01 said:
Thanks... I will hold off on flashing his kernel for the time being. It would be nice to get that working if possible.
Click to expand...
Click to collapse
Just tested, you should be able to boot maxwen kernel on cfxe, at least it does with cfxe ramdisk
test it out and tell how it wents
I do have some random reboots after +-10 minutes with this ROM. Can I provide you a logcat Anders?
anders3408 said:
Just tested, you should be able to boot maxwen kernel on cfxe, at least it does with cfxe ramdisk
test it out and tell how it wents
Click to expand...
Click to collapse
need to take a look at your ramdisk
if something special is required I can provide prebuilts with your ramdisk
Sent from my Find 5 using xda app-developers app
mavaee said:
I do have some random reboots after +-10 minutes with this ROM. Can I provide you a logcat Anders?
Click to expand...
Click to collapse
are you on the default kernel in this rom , and did a full wipe ?
Sure you can make a logcat , paste it via here
you can also submit a bug : here but please add log also
have not had a single random reboot at all, so its a bit wierd
anders3408 said:
are you on the default kernel in this rom , and did a full wipe ?
Sure you can make a logcat , paste it via here
you can also submit a bug : here but please add log also
have not had a single random reboot at all, so its a bit wierd
Click to expand...
Click to collapse
Yes I used the default kernel and coming from CM10.1 with a full wipe. I have to say I didn't experienced a reboot after all this afternoon so maybe it was just the ROM settling down.
---------- Post added at 04:21 PM ---------- Previous post was at 04:18 PM ----------
Logcat:
http://logcat.scheffsblend.com/view?id=285002
mavaee said:
Yes I used the default kernel and coming from CM10.1 with a full wipe. I have to say I didn't experienced a reboot after all this afternoon so maybe it was just the ROM settling down.
---------- Post added at 04:21 PM ---------- Previous post was at 04:18 PM ----------
Logcat:
http://logcat.scheffsblend.com/view?id=285002
Click to expand...
Click to collapse
What happens when you made that logcat? I'm not seeing any reboots? Hopefully you won't see such reboot again.
Sent from my Find 5 using XDA Premium HD app
Nice ROM.
Voice to text isn't functioning... I was going to try the app install from the Slim ROM site, but I know that doesn't work with the CM kernel. I know it works with Max's.
Anyway, other than that it's been stable for me. Wifi tethering worked, Battery seemed good for only running it 24 hrs or so.
charlatan01 said:
Nice ROM.
Voice to text isn't functioning... I was going to try the app install from the Slim ROM site, but I know that doesn't work with the CM kernel. I know it works with Max's.
Anyway, other than that it's been stable for me. Wifi tethering worked, Battery seemed good for only running it 24 hrs or so.
Click to expand...
Click to collapse
Its also using the CM's kernel. Can you send me a link to that app and I'll have a look.
Sent from my Find 5 using XDA Premium HD app
^ sure thing. Src install is found (thanks to the folks at Slim!) here

CAF problems list

Hi!
So, recently, I've noticed that CyanogenMod (CM) has adopted CodeAuroraForum (CAF) code, which is causing incompatibilities with AndroidOpenSourceProject (AOSP) code.
Problem #1:
Also, one of the common problems due to this is that flashing custom kernels (AOSP based), leads to color-display problems.
To fix this, a colorfix.zip has been provided by someone in the AOKP thread.
Also, there is poll in the AOKP website, about a shift to CAF code.
Now, AFAIK, this overwrites "liboverlay.so", in /lib. If this is all that need to be done to fix it, then how is a code problem?
Does this file have to be updated? What exactly does this file do?
What are the other problems associated with CAF code adoption?
Please contribute your opinions and list any other problems.
not happy with CAF.. stop using cm. there are plenty of better roms out there for you to choose from.
Agrees cm has gone to the poop house now.
Sent from my Nexus 4 using XDA Premium 4 mobile app
arvindch said:
Hi!
So, recently, I've noticed that CyanogenMod (CM) has adopted CodeAuroraForum (CAF) code, which is causing incompatibilities with AndroidOpenSourceProject (AOSP) code.
Problem #1:
Also, one of the common problems due to this is that flashing custom kernels (AOSP based), leads to color-display problems.
To fix this, a colorfix.zip has been provided by someone in the AOKP thread.
Also, there is poll in the AOKP website, about a shift to CAF code.
Now, AFAIK, this overwrites "liboverlay.so", in /lib. If this is all that need to be done to fix it, then how is a code problem?
Does this file have to be updated? What exactly does this file do?
What are the other problems associated with CAF code adoption?
Please contribute your opinions and list any other problems.
Click to expand...
Click to collapse
The issue with liboverlay.so is code incompatibilty between the ASOP source (custom kernels) with CM ROM using the CAF driver blobs. It's like a Chinese person speaking Chinese to an English only speaker. The fix is replacing the liboverlay.so with the ASOP liboverlay.so and back out that portion of the CAF. It's not a long term solution because it may cause other problems down the road.
There are some advantages using CAF, but it cause a divergence in kernels for the custom ROMs which may not be a good idea and causes maintainance headaches for the open source dev. For now lets just see what CM does with CAF.
Sent from my Nexus 4 using xda app-developers app
simms22 said:
not happy with CAF.. stop using cm. there are plenty of better roms out there for you to choose from.
Click to expand...
Click to collapse
kthejoker20 said:
Agrees cm has gone to the poop house now.
Sent from my Nexus 4 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
I agree that a solution is not using CM and CM-based ROMs. :|
However, I've started this thread to compile a list of problems that CAF code is causing and possible fixes, and to discuss the outcome of CAF code usage.
AtrixShan said:
The issue with liboverlay.so is code incompatibilty between the ASOP source (custom kernels) with CM ROM using the CAF driver blobs. It's like a Chinese person speaking Chinese to an English only speaker. The fix is replacing the liboverlay.so with the ASOP liboverlay.so and back out that portion of the CAF. It's not a long term solution because it may cause other problems down the road.
There are some advantages using CAF, but it cause a divergence in kernels for the custom ROMs which may not be a good idea and causes maintainance headaches for the open source dev. For now lets just see what CM does with CAF.
Sent from my Nexus 4 using xda app-developers app
Click to expand...
Click to collapse
What are the advantages to CAF code usage?
I read somewhere that Qualcomm contributes better, optimized code to the CAF, and hence, performance/quality may be better than AOSP. I don't have the source link, though.
Any ideas?
arvindch said:
What are the advantages to CAF code usage?
I read somewhere that Qualcomm contributes better, optimized code to the CAF, and hence, performance/quality may be better than AOSP. I don't have the source link, though.
Any ideas?
Click to expand...
Click to collapse
That's what I read, too. It's hard to say for now because I don't think CM is done with their CAF implementation. Let wait and see. The bottom line for me is using what works well on my Nexus 4. The headaches for the open source community does suck though. I used faux kernel since my first smart phone (Atrix 4g)
Sent from my Nexus 4 using xda app-developers app
AtrixShan said:
That's what I read, too. It's hard to say for now because I don't think CM is done with their CAF implementation. Let wait and see. The bottom line for me is using what works well on my Nexus 4. The headaches for the open source community does suck though. I used faux kernel since my first smart phone (Atrix 4g)
Sent from my Nexus 4 using xda app-developers app
Click to expand...
Click to collapse
Hmmm.
Same here - I've been using Franco.kernel since forever - I even bought the FKU pro app. It's giving me great performance and battery-life.
I don't want to stop using it! However, the features offered by SlimBean are too useful for me to ignore, as well.
Hence, if SB adopts the CAF code CM is using, since SB is based off CM, then I will have an extremely hard decision to make.
Not sure if anyone's noticed but you should check out your dmesg if reverting to an earlier liboverlay.so. I didn't notice any drastic changes in performance / battery life as a result, but that's not something I'm thrilled with.
For the time being, I've made some test builds with the two YCBYCR commits (from Oct 1)
It's based on Franco's r191.
The zips include the full OTG patch (kernel + ramdisk + ROM-side changes), but if you don't want the ramdisk/ROM-side features, just flash the boot.img or strip out the (non-)relevant parts from updater-script. It will still have the "otg code" in the kernel, but it shouldn't be something that'd affect usage at all.
4.3: 2013.10.13 0401ET r191: [JWR] [JSS/JLS]
Again, these have the two relevant commits cherry-picked and will require the recent liboverlay.so.
Just a temporary solution. I am curious though about how many other ROMs are affected by this-- CM forks. If say all new JLS/JSS ROMs require this, I might as well just keep on cherry-picking since that's the entire userbase practically. Obviously JWR will be a much tougher one.
ziddey said:
Not sure if anyone's noticed but you should check out your dmesg if reverting to an earlier liboverlay.so. I didn't notice any drastic changes in performance / battery life as a result, but that's not something I'm thrilled with.
For the time being, I've made some test builds with the two YCBYCR commits (from Oct 1)
It's based on Franco's r191.
The zips include the full OTG patch (kernel + ramdisk + ROM-side changes), but if you don't want the ramdisk/ROM-side features, just flash the boot.img or strip out the (non-)relevant parts from updater-script. It will still have the "otg code" in the kernel, but it shouldn't be something that'd affect usage at all.
4.3: 2013.10.13 0401ET r191: [JWR] [JSS/JLS]
Again, these have the two relevant commits cherry-picked and will require the recent liboverlay.so.
Just a temporary solution. I am curious though about how many other ROMs are affected by this-- CM forks. If say all new JLS/JSS ROMs require this, I might as well just keep on cherry-picking since that's the entire userbase practically. Obviously JWR will be a much tougher one.
Click to expand...
Click to collapse
This seems useful! :good:
Is this a patched franco kernel that works on CAF roms?
Could you clarify what this does? I'm sorta confused by all this.
from wat i know.. JSS faster than jwr but aosp jss has deadlock issues.. and caf solves deadlock issue..
Andre_Vitto said:
from wat i know.. JSS faster than jwr but aosp jss has deadlock issues.. and caf solves deadlock issue..
Click to expand...
Click to collapse
Really? I didn't know that. OK. One advantage then.
arvindch said:
Really? I didn't know that. OK. One advantage then.
Click to expand...
Click to collapse
JSS is a dev branch and has some GPU optimizations
== Sent from my CarbonMako ?? ==
---------- Post added at 11:35 PM ---------- Previous post was at 11:33 PM ----------
I have decided to quit CM as well due to their dumb decision about CAF
Now using Carbon ROM and to be honest it is non-bull**** one, packed with useful features, with wide group of fans and still developing for loads of devices
== Sent from my CarbonMako ?? ==
MaxFTW said:
\
[/COLOR]I have decided to quit CM as well due to their dumb decision about CAF
Now using Carbon ROM and to be honest it is non-bull**** one, packed with useful features, with wide group of fans and still developing for loads of devices
== Sent from my CarbonMako ?? ==
Click to expand...
Click to collapse
Hard to find stable roms on 4.3 these days.. PA is down the drain.. no update since a month.. too less features.. AOKP wont boot up for most ppl.. PAC is inherently unstable. I'm currently stock rooted.. seems like the most stable for me now..
AOKP nightly boot find for me, and I assume most other N4 have the same hardware as I do. "Official" AOKP don't put out nightlies that can't boot. People just need to not flash incompatible kernels and know what they're doing.
MaxFTW said:
JSS is a dev branch and has some GPU optimizations
---------- Post added at 11:35 PM ---------- Previous post was at 11:33 PM ----------
[/COLOR]I have decided to quit CM as well due to their dumb decision about CAF
Now using Carbon ROM and to be honest it is non-bull**** one, packed with useful features, with wide group of fans and still developing for loads of devices
Click to expand...
Click to collapse
Slimbean is also based off CM code and I love Slimbean's feature set.
Luckily they haven't merged CAF changes YET. :fingers-crossed:
I'm also testing crDroid, since I like Halo; however, they're based right off CM 10.2, so I need to flash colorfix.zip to get it working with Franco.kernel.
Andre_Vitto said:
Hard to find stable roms on 4.3 these days.. PA is down the drain.. no update since a month.. too less features.. AOKP wont boot up for most ppl.. PAC is inherently unstable. I'm currently stock rooted.. seems like the most stable for me now..
Click to expand...
Click to collapse
eksasol said:
AOKP nightly boot find for me, and I assume most other N4 have the same hardware as I do. "Official" AOKP don't put out nightlies that can't boot. People just need to not flash incompatible kernels and know what they're doing.
Click to expand...
Click to collapse
Hmm.
I've never tried 'pure AOKP'. I've use ROMs which kang stuff from AOKP sources though. Same goes for CM - I've never used pure CM. I love using hybrid ROMs - Best of all worlds!
I agree. Sadly, PA is stuck on an RC2 since a month.
I read that they're waiting for 4.4 to drop, but IMO, atleast they could release another RC in the meanwhile, to fix bugs.
Some ROMs have merged all the latest Halo commits and have fixed some bugs I encountered on PA 3.99RC2, so I'm using them (hybrid ROMs) instead.

Potential Marshmallow for S3 GT-I9300 (Achieved)

Our device is still running because of XDA and the developers. And this 3 year + device is still in race to taste the Marshmallow .​
Let us use this thread for discussion related to it.​
And all of this has become possible because of the recognized developers @JustArchi @dhiru1602 @mcgi5sr2 @Moster2 @arter97, Christian Balster (OMNI team), @forkbomb444 Haxynox team, Nameless team (Sorry, in case I missed someone)​
There are 3 projects going on for getting a build of Marshmallow.(Achieved)
The Haxynox Team --- [ AOSP M is out --- Check it out ]
The Official CM --- [ The First to come --- CM 13 Thread Link ] && { It's happening, nightlies are here - Official CM-13 Download Link }
The Nameless Team --- [ It will happen ]
For the list of Marshmallow ROM's available for S3 GT-I9300, Click below:
Official CM13 : Thread Link
Official RESSURRECTION REMIX : Thread Link
Temasek's UNOFFICIAL CyanogenMod 13 : Thread Link
Official Mokee Open Source Project : Thread Link
The CyanPop 6.x.x Project : Thread Link
Minimal OS : Thread Link
Android Ice Cold Project : Thread Link
The Haxynox Team​
They are the first to initialize the process of building Marshmallow for our device tree.
Developers: @mcgi5sr2 @Ivan_Meler @dexter93
You can get the latest 'M' AOSP from here : Haxynox AOSP 'M' Link
Github: Link
Official CM 13​
The development process of CM 13 has just started few days back.
Developers: Simon Shields , CM team.
Gerrit Link: I9300-M-BringUp || smdk4412
Here comes the first building project of Marshmallow CM 13 :
CM 13 Thread Link
PS: No one knows who XYZ is on XDA. I searched for him on Github and came through this account of a developer ,which has the same commits as published on Official CM Gerrit.
The link of the Github is keepcalm444 and may be it is XYZ's user name.
An XDA account matched it forkbomb444 ( The email used for commit in Official CM Gerrit Review matches it .
(I am not sure about it)
The unknown developer is none other than @forkbomb444
Official Nameless Team​
They have asserted that they will definitely release Marshmallow for our device.
Source : Google+ Post
Developers: @dhiru1602 , Nameless Team.
You can follow their work on the thread here : Nameless ROM Link
Google+ Community (They are active here): Nameless ROM Official Community
Gerrit: Nameless ROM Gerrit
Note: I will update any information if something new happens. I welcome you to suggest new thoughts or new information.
You're forgetting Bliss team and their maintainers and developers who are also working to bring marshmallow to our phone. They've done a wonderful job on blisspop (I can tell you myself since I've been using their ROM as a daily driver for past weeks and I have no complaints about it)
Yes forkbomb(xda) this guy is maintaining cm13 official i ask on irc(he use this nickname)
That CM "Maintainer" is just using old commits from evryone else at the list and most of the time violating authorship by just squashing commits and putting his name on it
Romflasher69 said:
You're forgetting Bliss team and their maintainers and developers who are also working to bring marshmallow to our phone. They've done a wonderful job on blisspop (I can tell you myself since I've been using their ROM as a daily driver for past weeks and I have no complaints about it)
Click to expand...
Click to collapse
I love Blisspop too! I have tried lots of ROMS. At the end, blisspop! Thanks.
Ivan_Meler said:
That CM "Maintainer" is just using old commits from evryone else at the list and most of the time violating authorship by just squashing commits and putting his name on it
Click to expand...
Click to collapse
Maybe not because he has pushed some commits of his own also.
---------- Post added at 02:44 PM ---------- Previous post was at 02:38 PM ----------
And BTW are you guys sure that we will be getting the official CM13.0? No changes in github from last 2 days.
sunny1234590 said:
Maybe not because he has pushed some commits of his own also.
---------- Post added at 02:44 PM ---------- Previous post was at 02:38 PM ----------
And BTW are you guys sure that we will be getting the official CM13.0? No changes in github from last 2 days.
Click to expand...
Click to collapse
I didnt see his own changes at all they are just changes from other devs with his name on top..
sunny1234590 said:
Maybe not because he has pushed some commits of his own also.
---------- Post added at 02:44 PM ---------- Previous post was at 02:38 PM ----------
And BTW are you guys sure that we will be getting the official CM13.0? No changes in github from last 2 days.
Click to expand...
Click to collapse
Dear Brother, building a ROM is not like a game.
Things are always not pushed directly into gerrit everyday, it is a long process than we think.
And coming to another thing, we (normal users) have very less idea about development. It is better to keep calm than raising unnecessary issues. This issue can only be solved by a proper answer from the CM developer.
Romflasher69 said:
You're forgetting Bliss team and their maintainers and developers who are also working to bring marshmallow to our phone. They've done a wonderful job on blisspop (I can tell you myself since I've been using their ROM as a daily driver for past weeks and I have no complaints about it)
Click to expand...
Click to collapse
bingkeye said:
I love Blisspop too! I have tried lots of ROMS. At the end, blisspop! Thanks.
Click to expand...
Click to collapse
I didn't forget them. I respect their work.
Blisspop along with many other projects like Resurrection Remix, Euphoria OS, crDroid and many other are dependent on Archi device tree or Nameless device tree or Haxynox tree or some other (ROM source would be from respective projects).
Correct me, if I am wrong. I would definitely add them if someone from their team are working on bringing our device tree for 'M'.
Ivan_Meler said:
I didnt see his own changes at all they are just changes from other devs with his name on top..
Click to expand...
Click to collapse
Look onto github you'll see. However, I might be wrong too.
sunny1234590 said:
Look onto github you'll see. However, I might be wrong too.
Click to expand...
Click to collapse
Once check the below post carefully.
Ivan_Meler said:
I didnt see his own changes at all they are just changes from other devs with his name on top..
Click to expand...
Click to collapse
You would get the answer you want if you understand the bold/underlined/italicized part.
RajashekarReddy.A said:
Once check the below post carefully.
You would get the answer you want if you understand the bold/underlined/italicized part.
Click to expand...
Click to collapse
Selinux M bringup commit was of which developer? Wasn't it Simon himself? :/
Romflasher69 said:
You're forgetting Bliss team and their maintainers and developers who are also working to bring marshmallow to our phone. They've done a wonderful job on blisspop (I can tell you myself since I've been using their ROM as a daily driver for past weeks and I have no complaints about it)
Click to expand...
Click to collapse
Blisspop isn't exactly the most trustable ROM source I know. They've been caught kanging (stealing others work) many times and I'm sorry to say, but Blisspop isn't going anywhere until CM, Nameless or Haxynox do something.
Yes, it's getting a slight bit political if you're wondering.
I'm just tasting the flavor of the Marshmallow in my xt1069, but I prefer the i9300 because it's better than him (in my opinion, obviously). But, a little question about the future: can i9300 smell or taste Nutella? (I'm talking about a future Android N)
Talking about the ROM's, I feel very proud because we have so many people that don't let a device of this caliber die. Since I don't have money to donate, let me give my special thanks to all of you who don't let it go down. I'm very grateful.
moisespereira01 said:
I'm just tasting the flavor of the Marshmallow in my xt1069, but I prefer the i9300 because it's better than him (in my opinion, obviously). But, a little question about the future: can i9300 smell or taste Nutella? (I'm talking about a future Android N)
Talking about the ROM's, I feel very proud because we have so many people that don't let a device of this caliber die. Since I don't have money to donate, let me give my special thanks to all of you who don't let it go down. I'm very grateful.
Click to expand...
Click to collapse
It's a broad question.
First, let us hope if we could get a usable 'M' build first.
RajashekarReddy.A said:
It's a broad question.
First, let us hope if we could get a usable 'M' build first.
Click to expand...
Click to collapse
Too early, right? But I think we have a nice hardware to get M. Will it have a better Ram management?
Ivan_Meler said:
That CM "Maintainer" is just using old commits from evryone else at the list and most of the time violating authorship by just squashing commits and putting his name on it
Click to expand...
Click to collapse
Look, while I did do that, I think you'll find that it's been fixed. I'm sorry I did that, and it won't happen again.
Now, re: using old commits: did you *really* expect me to spend hours on end doing work that's already been done? It makes a lot more sense to focus on work that hasn't been done yet, rather than trying to redo everyone's work.
Now, if you have any issues with what I'm doing, feel free to PM me
Exactly! This is what my point is. And apart from that he himself is pushing some commits of his own. Make sure you guys checks at least. Yesterday there was two new commits which are not yet merged though.
Thanks a lot Simon @forkbomb444
forkbomb444 said:
Look, while I did do that, I think you'll find that it's been fixed. I'm sorry I did that, and it won't happen again.
Now, re: using old commits: did you *really* expect me to spend hours on end doing work that's already been done? It makes a lot more sense to focus on work that hasn't been done yet, rather than trying to redo everyone's work.
Now, if you have any issues with what I'm doing, feel free to PM me
Click to expand...
Click to collapse
I'm pretty sure proper authorship is the only issue here
Gokulbalram said:
I'm pretty sure proper authorship is the only issue here
Click to expand...
Click to collapse
He did give proper authorship to developers. Check github. Anyways, just a request to all the developers please help him to get the official CM13.0 for S3 running.

CyanogenMod for Pixel v1

FIRST TEST BUILD OUT
Since the MTK variants in the second gen Android One devices have steadfastly been ignored for development, I have taken it upon me to ensure that there is no dearth of top-of-the-line trees for any brave person wanting to build for this device. Here are my sources :
Device Tree : https://github.com/MSF-Jarvis/android_device_google_seedmtk
Common Tree (necessary) : https://github.com/MSF-Jarvis/android_device_google_sprout-common
Kernel Source (untested) : [url]https://github.com/MSF-Jarvis/android_kernel_mediatek_sprout[/URL]
Vendor Tree : https://github.com/MSF-Jarvis/proprietary_vendor_google_seedmtk-2ndgen
NOTE TO TESTERS : Please try getting logcats for me since it is IMPOSSIBLE to do anything without even knowing why something is broken
MSF Jarvis said:
Since the MTK variants in the second gen Android One devices have steadfastly been ignored for development, I have taken it upon me to ensure that there is no dearth of top-of-the-line trees for any brave person wanting to build for this device. Here are my sources :
Device Tree : https://github.com/MSF-Jarvis/android_device_mediatek_sprout
Common Tree (necessary) : https://github.com/MSF-Jarvis/android_device_google_sprout-common
Kernel Source (untested) : https://github.com/MSF-Jarvis/android_kernel_mediatek_sprout
Vendor Tree : https://github.com/MSF-Jarvis/proprietary_vendor_google_sprout-2ndgen
I am currently negotiating for a server with one of my dear friends, and will commence builds as soon as I can wrangle one out from him
Everyone is welcome to help me out with this project. I tried getting @DHARMESH17 onto it but apparently it seems he's not very interested or dedicated to the cause.
And oh, almost forgot, here's a local manifest to prevent manually cloning things : https://github.com/TeamRedux/local_manifests/tree/cm-13.0-sprout
Click to expand...
Click to collapse
Bro I am completely interested in it but because of some barriers I was unable to continue the project but now I am completely feee and start development on rom
DHARMESH17 said:
Bro I am completely interested in it but because of some barriers I was unable to continue the project but now I am completely feee and start development on rom
Click to expand...
Click to collapse
I would like some proof of your ability with ROM compiling before I let you in on my server.
Ashiron said:
Give me full details.
Start to end.
100% success result
??
Click to expand...
Click to collapse
Details as in??
The kernel source has been imported to my Github and I have also set-up Continuous Integration on it through Travis-CI, build progress can be tracked here.
I would like to thank @akhilnarang whose ThugLife scripts have been used to compile the kernel inside the CI. I couldn't include your name in the commits, but the original copyright notice has been retained in the spirit of open source.
I have been informed through Google Plus that @DHARMESH17 has been in the hospital for some time now, and @faddat is currently in China, so the project has been put on hold for now.
Work will begin tomorrow
You can get the stock source to boot on pixel?
A friend of mine has tried, it dosen't boot
akhilnarang said:
You can get the stock source to boot on pixel?
A friend of mine has tried, it dosen't boot
Click to expand...
Click to collapse
Kernel source? Of course not, I believe it's specific to the first gen sprout devices, as I found out earlier this day. I guess I'll have to end up messing with the device tree and see if I can sneak in a prebuilt kernel somewhere inside. One query though, since you've made an appearance, if I use a custombootimg.mk for userdebug builds, will it prepare the boot.img as per the recipe given there? Because as TWRP maintainer for the htc pico, I have to force it to use LZMA compression for the ramdisk to make it fit, and for that I set a ifeq into the boardconfig to use the customrecoveryimg.mk I put in the device tree, if build variant is eng. If it will work on boot.img and userdebug, then I may very well be able to fool CM's build system and use a prebuilt kernel.
If I'm not making myself clear, please do hop on to #team-redux on freenode and we'll discuss it at length and hopefully arrive at a solution
MSF Jarvis said:
Kernel source? Of course not, I believe it's specific to the first gen sprout devices, as I found out earlier this day. I guess I'll have to end up messing with the device tree and see if I can sneak in a prebuilt kernel somewhere inside. One query though, since you've made an appearance, if I use a custombootimg.mk for userdebug builds, will it prepare the boot.img as per the recipe given there? Because as TWRP maintainer for the htc pico, I have to force it to use LZMA compression for the ramdisk to make it fit, and for that I set a ifeq into the boardconfig to use the customrecoveryimg.mk I put in the device tree, if build variant is eng. If it will work on boot.img and userdebug, then I may very well be able to fool CM's build system and use a prebuilt kernel.
If I'm not making myself clear, please do hop on to #team-redux on freenode and we'll discuss it at length and hopefully arrive at a solution
Click to expand...
Click to collapse
No need of fooling any system, you can happily use a prebuilt kernel as it is to build CM
akhilnarang said:
No need of fooling any system, you can happily use a prebuilt kernel as it is to build CM
Click to expand...
Click to collapse
Go ahead and try
MSF Jarvis said:
Go ahead and try
Click to expand...
Click to collapse
I have, and I often use a prebuilt kernel, no issues. What do you get?
Sent from my Nexus 5X using XDA-Developers mobile app
akhilnarang said:
I have, and I often use a prebuilt kernel, no issues. What do you get?
Sent from my Nexus 5X using XDA-Developers mobile app
Click to expand...
Click to collapse
AOSP based ROMs are a different story, CyanogenMod raises this exception when you try using a prebuilt kernel :
```
Using a prebuilt kernel is deprecated and not allowed
Please add your kernel source to your BoardConfig.mk
```
Or something to that tune, been months since I ran a compile for any ROM(Server's late in coming, @faddat is a busy man )
I have got a server now, and will commence builds tomorrow. Stay tuned!
MSF Jarvis said:
AOSP based ROMs are a different story, CyanogenMod raises this exception when you try using a prebuilt kernel :
```
Using a prebuilt kernel is deprecated and not allowed
Please add your kernel source to your BoardConfig.mk
```
Or something to that tune, been months since I ran a compile for any ROM(Server's late in coming, @faddat is a busy man )
Click to expand...
Click to collapse
It still builds, as long as you've specified the PRODUCT_COPY_FILE properly
Anyway, why did you base your trees on the old cm-12.1 trees of Varun
If you're trying cm-13.0 then base on the latest cm-13.0 from CyanogenMod GitHub
Sent from my Nexus 5X using XDA-Developers mobile app
akhilnarang said:
It still builds, as long as you've specified the PRODUCT_COPY_FILE properly
Anyway, why did you base your trees on the old cm-12.1 trees of Varun
If you're trying cm-13.0 then base on the latest cm-13.0 from CyanogenMod GitHub
Sent from my Nexus 5X using XDA-Developers mobile app
Click to expand...
Click to collapse
I realised that earlier today, so I rebased my updates onto the snapshot trees and pushed it to my Github. The local manifest has been updated with the new branch as well.
About the prebuilt kernel, you use PRODUCT_COPY_FILES for copying the zImage ?? @thewisenerd once mentioned its a terribly ****ty idea, but you're more updated regarding building and ****, so I'll take your word. Just a quick query, what'll be the out location of the kernel? ($OUT/kernel ??)
MSF Jarvis said:
I realised that earlier today, so I rebased my updates onto the snapshot trees and pushed it to my Github. The local manifest has been updated with the new branch as well.
About the prebuilt kernel, you use PRODUCT_COPY_FILES for copying the zImage ?? @thewisenerd once mentioned its a terribly ****ty idea, but you're more updated regarding building and ****, so I'll take your word. Just a quick query, what'll be the out location of the kernel? ($OUT/kernel ??)
Click to expand...
Click to collapse
Yep
Code:
PRODUCT_COPY_FILES := $(LOCAL_PATH)/kernel:kernel
Sent from my Nexus 5X using XDA-Developers mobile app
@akhilnarang, you free some night? I'll be needing help as far as I can see.
Anyways, ever had a problem with cts/apps/ctsVerifier throwing exceptions? My build refuses to start! Not to mention that repo is also being very hard on me, not syncing projects, throwing exceptions while unpacking and ****. Gonna rebase to nightly level, currently on snapshot 1.
Official TWRP now available : http://forum.xda-developers.com/cro...al-android-development/recovery-twrp-t3353364
MSF Jarvis said:
I would like some proof of your ability with ROM compiling before I let you in on my server.
Click to expand...
Click to collapse
Bro still want proof LoL ??

Categories

Resources