Related
i have being waiting for 2.3 a long time,
Check cyanogenmod forum for updates
obggbo said:
i have being waiting for 2.3 a long time,
Click to expand...
Click to collapse
This is why they have ditched XDA, this kind of persistence from people who have no idea how things work. It takes a very long time to get things like CM7 working. If you think you could do a better job why not give it a go yourself? These guys are giving up their spare time and are doing this for fun, it's no longer fun if you constantly have people nagging you about it. Just wait, it will come.
These guys are giving up their spare time and are doing this for fun, it's no longer fun if you constantly have people nagging you about it
A lot like the pressure Darky gets too keep changing stuff .
jje
hypocrisy is lame
I apply the previous poster's screen name as your reply to this thread.
Sent from my GT-I9000 using Tapatalk
I'm pretty sure this guy just asked a question, it doesn't seem to warrant a vitriolic reply.
doc v7.x.x, jpy, voodoo 5.1, va orange.
woolf clubs said:
I'm pretty sure this guy just asked a question, it doesn't seem to warrant a vitriolic reply.
doc v7.x.x, jpy, voodoo 5.1, va orange.
Click to expand...
Click to collapse
Couldnt agree more. Why do people get so arsey when someone asks a question - it usually takes longer for them to put down the person for asking the question than what the answer was in the first place!
And all this "these guys only do it for fun" - rubbish. There's plenty of money to be made via donations.
Some people do this work for fun in their spare time, some get donations for this work... and others simply ask what stage their work is at. Wheres the need to get arsey at simple question?...
Far too many negative ppl in this place.. When I read through these forums it seems alot of ppl cant wait to jump down other ppls throats and start being rude and nasty. Some ppl here need to relax.
As you can see from this many things still have to be done
http://code.google.com/p/cyanogenmod7-for-samsung-galaxys/
What's working:
MTD
Radio
Audio
GPS
Wifi
Bluetooth
3D
HQ Video PLayback
internal SD-Card
external SD-Card
Most Sensors
What's not working:
LQ Video Playback (overlay problem)
Camera (should work but is black because of the overlay problem)
Polling problem on RIL (works after lock and unlock)
2G/3G toggle (works if no data connection is active)
Compass (works not at 100%)
USB sharing of internal SD-Card
commands: reboot recovery, reboot download (maybe not possible to implement)
FM-Radio
TV-Out
Charging if Phone is powered off causes the phone to boot
Random reboots (not often)
couldnt agree with you more
Could someone explain the "Polling problem on RIL" ?
I know its something to do with closed source drivers but what it is eludes me...
Can't wait for this ROM.
I'm really excited for this release too, man :]
I am posting here because I haven't made the requisite 10 posts to get access to post to the development forum. Is there a developer that would be willing to help me here?
Wanted:
Dev assistance with a persistent sleep-lock and/or full-charge lock issue experienced with nearly all non-stock roms on a Samsung i897 with a fresh flash of CM 10. (CM 10 is not the relevant detail, this issue has happened with every non-stock-based rom based on anything newer than and including GB. (so GB/ICS/JB suffer this issue)
What are we calling sleep-lock?
Sleep-lock in this case is being defined as a spontaneous shutdown, lockup (requiring removal of battery to restart), or spontaneous restart of the Android OS. I understand that these three results may or may not be the product of the same root cause (in fact they're probably not) but I'm throwing them in the same bucket because they seem to be randomly happening when the phone is in a sleeping state.
What are we calling full-charge lock?
Full-Charge lock in this case is being defined as a spontaneous shutdown or lockup (requiring removal of battery to restart; I do not seem to suffer spontaneous restarts while on the charger). I understand that these two results may or may not be the product of the same root cause (in fact they're probably not) but I'm throwing them in the same bucket because they seem to all happen when the device is on the charger, but most often when the phone reaches or is near a full charge.
Troubleshooting done to date:
I have tried various ROMs over a long period of time, some were better than others, but they were all victims of this behavior. It doesn't seem to be device-specific (read as hardware) related but ever since DarkyRom that I tried shortly after I got this device a couple years ago, I have had this behavior. Stock ROMs do not suffer this behavior.
Who are you working with?
I am a Sr. Technical Team Leader for a Fortune 1000 VoIP software company and am well versed in troubleshooting methodology. I am somewhat newbish in the ways of logcat so I would ask for a little patience there, but am well versed in Windows, Linux, and many parts of the Android OS and flashing process including Odin, Hiem. and CWM. I'm seeking developer assistance because I am completely inept at code development.
The device that we're working with is a non-production (not relied upon for daily use) and I have no problem leaving it running with a logcat on it, or flashing any ROM you would ask for troubleshooting purposes. That said, the goal is to get the stable CM10 running without reboots or lockups.
Thank you in advance for your time and assistance.
--ChipSharp(DotCom)
chipsharpdotcom said:
I am posting here because I haven't made the requisite 10 posts to get access to post to the development forum. Is there a developer that would be willing to help me here?
Wanted:
Dev assistance with a persistent sleep-lock and/or full-charge lock issue experienced with nearly all non-stock roms on a Samsung i897 with a fresh flash of CM 10. (CM 10 is not the relevant detail, this issue has happened with every non-stock-based rom based on anything newer than and including GB. (so GB/ICS/JB suffer this issue)
What are we calling sleep-lock?
Sleep-lock in this case is being defined as a spontaneous shutdown, lockup (requiring removal of battery to restart), or spontaneous restart of the Android OS. I understand that these three results may or may not be the product of the same root cause (in fact they're probably not) but I'm throwing them in the same bucket because they seem to be randomly happening when the phone is in a sleeping state.
What are we calling full-charge lock?
Full-Charge lock in this case is being defined as a spontaneous shutdown or lockup (requiring removal of battery to restart; I do not seem to suffer spontaneous restarts while on the charger). I understand that these two results may or may not be the product of the same root cause (in fact they're probably not) but I'm throwing them in the same bucket because they seem to all happen when the device is on the charger, but most often when the phone reaches or is near a full charge.
Troubleshooting done to date:
I have tried various ROMs over a long period of time, some were better than others, but they were all victims of this behavior. It doesn't seem to be device-specific (read as hardware) related but ever since DarkyRom that I tried shortly after I got this device a couple years ago, I have had this behavior. Stock ROMs do not suffer this behavior.
Who are you working with?
I am a Sr. Technical Team Leader for a Fortune 1000 VoIP software company and am well versed in troubleshooting methodology. I am somewhat newbish in the ways of logcat so I would ask for a little patience there, but am well versed in Windows, Linux, and many parts of the Android OS and flashing process including Odin, Hiem. and CWM. I'm seeking developer assistance because I am completely inept at code development.
The device that we're working with is a non-production (not relied upon for daily use) and I have no problem leaving it running with a logcat on it, or flashing any ROM you would ask for troubleshooting purposes. That said, the goal is to get the stable CM10 running without reboots or lockups.
Thank you in advance for your time and assistance.
--ChipSharp(DotCom)
Click to expand...
Click to collapse
There are many things that can cause what we call SoD (sleep of death). First off, if you have deep idle checked on, remove that (in your ROM options).
What are the changes/mods you made after flashing CM10 (assuming stable version)?
Do you OC/UV?
And finaly, after checking for those things, there's a possible fix. It seems to have work on those who don't have a hardware issue, flashing I9000 bootloaders. The link in my sig guides you through it for the I897. (I9000 being the international version of the captivate)
If you end up going that route, I would do a clean flash. So flash stock software (KK4 no BLs) through Odin or Heimdall, flash the BLs, flash corn kernel to get root and finally flash CM10.
There are no real fix if it's a hardware issue that I'm aware of but hopefully it isn't. Also, I know you want to run CM10 on it but some people reported that running Mosaic 9 fixed their SoD problem. (It is the last I9000 ported ROM)
BWolf56 said:
There are many things that can cause what we call SoD (sleep of death). First off, if you have deep idle checked on, remove that (in your ROM options).
What are the changes/mods you made after flashing CM10 (assuming stable version)?
Do you OC/UV?
And finaly, after checking for those things, there's a possible fix. It seems to have work on those who don't have a hardware issue, flashing I9000 bootloaders. The link in my sig guides you through it for the I897. (I9000 being the international version of the captivate)
If you end up going that route, I would do a clean flash. So flash stock software (KK4 no BLs) through Odin or Heimdall, flash the BLs, flash corn kernel to get root and finally flash CM10.
There are no real fix if it's a hardware issue that I'm aware of but hopefully it isn't. Also, I know you want to run CM10 on it but some people reported that running Mosaic 9 fixed their SoD problem. (It is the last I9000 ported ROM)
Click to expand...
Click to collapse
Thanks for this information. I have read most of this information before, but I appreciate the info nonetheless.
Post install I don't do any customization in terms of OC/UV. So I'm fairly certain that's not it.
I'll run through what you've suggested here in order and see what I get. The specific order is the part that I've found unique. It may take a couple days to get back to you as my test cases involve a couple of charges/discharges, some "normal use" cases etc. I'll let you know my results.
Thank you again for your willingness to help. I'd like to maintain the usefullness of this device and I appreciate your assistance to that end.
--ChipSharp(DotCom)
chipsharpdotcom said:
Thanks for this information. I have read most of this information before, but I appreciate the info nonetheless.
Post install I don't do any customization in terms of OC/UV. So I'm fairly certain that's not it.
I'll run through what you've suggested here in order and see what I get. The specific order is the part that I've found unique. It may take a couple days to get back to you as my test cases involve a couple of charges/discharges, some "normal use" cases etc. I'll let you know my results.
Thank you again for your willingness to help. I'd like to maintain the usefullness of this device and I appreciate your assistance to that end.
--ChipSharp(DotCom)
Click to expand...
Click to collapse
If you tried the other stuff and the I9000 bootloaders don't work, chances are that it's a hardware problem.
BWolf56 said:
If you tried the other stuff and the I9000 bootloaders don't work, chances are that it's a hardware problem.
Click to expand...
Click to collapse
I'm going to give it a try right now....I'm less inclined to buy into the hardware theory though without having these problems on the Stock ROM.
chipsharpdotcom said:
I'm going to give it a try right now....I'm less inclined to buy into the hardware theory though without having these problems on the Stock ROM.
Click to expand...
Click to collapse
Try upping the voltage/minimum clock speed. That worked for me when I was running cm9 with the glitch kernel.
Sent from my Apple IIe
billyjed said:
Try upping the voltage/minimum clock speed. That worked for me when I was running cm9 with the glitch kernel.
Sent from my Apple IIe
Click to expand...
Click to collapse
Thanks for the tip...I'll try that if all of the above doesn't work. At this point, I'm all flashed up and running test cases.
So none of the suggestions here (unfortunately) provided me any different results. That said, I have discovered a couple of different variables that may play a part in this.
1.) This issue only seems to come up when I have the device plugged into power only, not when I have it plugged into a computer.
2.) I think this may be related to trying to sleep while still maintaining the clock application. It seems that when I see this most often, it is when I am plugged into the wall, and I have an alarm set. I was able to be plugged into the wall overnight last week and have no problems without the alarm set, but when I set the alarm, I had the sleep-lock issue (and moreover as you would expect, my alarm did not sound).
Again, I have none of these problems with the stock ROM. I'm going to continue to test on this and hack around on it to see if I can hunt this down, but my concern is that the very things that allow me to troubleshoot are the same things that keep the device from reproducing the error.
You can subscribe to this thread if you care to continue watching the progress, or if you have any similar experiences or potential solutions, but this is one of those issues that if I don't find the root cause, it's going to drive me bat-s%#$-f&@!#%-crazy. I'm aware that even if I get to the root cause I will likely never see a fix for the problem being that this device is so old, but this is caught in my teeth now, and I'm going to have a hard time letting it go.
As always thank you all for your assistance and participation.
chipsharpdotcom said:
So none of the suggestions here (unfortunately) provided me any different results. That said, I have discovered a couple of different variables that may play a part in this.
1.) This issue only seems to come up when I have the device plugged into power only, not when I have it plugged into a computer.
2.) I think this may be related to trying to sleep while still maintaining the clock application. It seems that when I see this most often, it is when I am plugged into the wall, and I have an alarm set. I was able to be plugged into the wall overnight last week and have no problems without the alarm set, but when I set the alarm, I had the sleep-lock issue (and moreover as you would expect, my alarm did not sound).
Again, I have none of these problems with the stock ROM. I'm going to continue to test on this and hack around on it to see if I can hunt this down, but my concern is that the very things that allow me to troubleshoot are the same things that keep the device from reproducing the error.
You can subscribe to this thread if you care to continue watching the progress, or if you have any similar experiences or potential solutions, but this is one of those issues that if I don't find the root cause, it's going to drive me bat-s%#$-f&@!#%-crazy. I'm aware that even if I get to the root cause I will likely never see a fix for the problem being that this device is so old, but this is caught in my teeth now, and I'm going to have a hard time letting it go.
As always thank you all for your assistance and participation.
Click to expand...
Click to collapse
Have you tried it with a different clock app? I mean, if I understand this correctly, it seems to be narrowed down to your current clock apk, which is different than the stock GB one. So I would suggest freezing (or unistalling) your current one with Tibu and trying a different one.
That's actually my next step.
I'm not sure it's accurate to say that I have it narrowed down to the clock app, I simply noted that I reproduced the issue on wall power and with the alarm set. That could all be coincidence. I need to try to reproduce those scenarios more reliably and in a more controlled method.
Do you know of an app I could install that would cause my battery to discharge fairly quickly? It would speed up my troubleshooting.
chipsharpdotcom said:
That's actually my next step.
I'm not sure it's accurate to say that I have it narrowed down to the clock app, I simply noted that I reproduced the issue on wall power and with the alarm set. That could all be coincidence. I need to try to reproduce those scenarios more reliably and in a more controlled method.
Do you know of an app I could install that would cause my battery to discharge fairly quickly? It would speed up my troubleshooting.
Click to expand...
Click to collapse
Haha first time I ever get that question but leaving your camera on should do the job (or video playing)
Ok, it goes without saying that ART support isn't really a given by any means and could be quite some time even if it comes out. I'm not asking here if it will or even specifically when. Rather, I'm wondering if there's anything specific that I can watch/subscribe to or whatever where at such a time as ART is finally supported (if it ever is, but hopefully with Android's future going permanently to ART there is hope that it will) I can know. I switched some time ago and for me at least it does so much better than Dalvik that I just can't really bear to switch back even for Xposed, but I really miss it.
Subscribe to the releases thread in this forum (it's a sticky). Also, the Xposed Installer would get updated when it happens, so you'll see it from the app as well.
After Installing Custom Mods and rooting on Oxygen OS I was experiencing a Android System battery Drain .
Also in custom Roms based On OOS I also had the same problem.
I was draining 35-40 percentage of my battery in a charge cycle.
I searched alot past 2-3 days on my phone to see which process is causing this Drain problem.
I found many but stoping them didn't fix it .
Finally today when I found that after SuperSU was installed
It was causing the Drain so I found a fix for this
Fix for all Roms having this problem
-Go to SuperSU app
-Settings menu
-Enable trust system User
-and enable grant permission during boot
-Then put the phone on flight mode and wait for it to cool down.
If this doesn't work
-Try setting default access to grant
-Enable MultiUser access
Hit the thanks button if this helps
Also tell me if this helps in the comments
Remember to follow all steps
Original Post here
https://forum.xda-developers.com/showpost.php?p=71082541&postcount=72
Testing ... I post the result at the end of the cycle.
Doesn't work still battery drain and phone always warm
Sent from my ONEPLUS A3003 using Tapatalk
@Nishidh
Thanks for sharing but both solutions are security risk. Maybe Magisk is solution till SuperSu is fixed (hoping that it IS the culprit).
DrunkenDragon said:
Doesn't work still battery drain and phone always warm
Click to expand...
Click to collapse
Try to delete all of the mkv files. That helps for me. No battery drain at all
i would say "kindda" help. cause still android system drains. but, a bit less then before. i would like to see some more days.
I switched to Magisk and drain is still there so reason is something else seemingly. It has something to do with FW/Modem. We all need to deluge OnePlus with requests to fix this mess.
Helps me
My current battery cycle
For me clearing the Google Play Services database solved the battery drain.
Apps,
Google play services
Storage
Manage Space
Clear all data
I then remained on that screen and restarted the phone into recovery without returning to the launcher.
In recovery clear cache only.
Reboot
Since then I have had no problems at all (though I am running complete stock no root)
No data is lost but you will have to add cards to android pay and set a couple of other items when prompted (like default backup account etc).
Sent from my ONEPLUS A3003 using Tapatalk
I mean no disrespect to the OP when posting this..
Isn't setting default root access to "grant" a crazy big security risk? Potentially malicious apps could reboot recovery in the middle of the night, flash some REAL spyware and feed back all your passwords without you knowing and could compromise your online accounts, still have to be installed first or some exploit would have to be found, but it just seems the risks outweigh the benefits.
Are you sure it's not another app you've consistently installed? F2fs? Clean installs + factory resets? Checked your signal strength lately? Wi-Fi + Bluetooth scanning? Facebook/whatsapp/etc installed? Google location history? Different versions of twrp? Titanium backups? Uncheck the the option in android settings to Backup and restore android apps? Installed several versions of older supersu?[ R4, r3, r2, r1, r2d2?]Franco kernel? [HIGHLY RECOMMEND. All the other kernels I've tried leave my device pretty warm, but franco keeps it cool), or Anoint your phone with luxurious oils, passionately bathe it and whisper sweet things into its microphone? [References here->
]
I just wanted to make my thoughts known, some newer users to root might come by, try and follow these steps hoping for SOT gains, and needlessly compromise their phone in the process.
If you persist in believing cf supersu is the root cause (that's a knee slapper!!) I think trying another supersu might be a better way to go than ticking all those options. Say like, phh's or CWM.
Again, I mean no disrespect to the OP. Just my thoughts.
Forget about SuperSU, You guys have no idea what causes the andriod OS drain after flashing.... So stop blaming kernel, SuperSU, gplay services etc.. The answer is out there in forums.. Feel free to browse and search for it...
sarus_b said:
Forget about SuperSU, You guys have no idea what causes the andriod OS drain after flashing.... So stop blaming kernel, SuperSU, gplay services etc.. The answer is out there in forums.. Feel free to browse and search for it...
Click to expand...
Click to collapse
I saw you also sprayed ppl with their own bs on Blu spark thread. All i can say is I roam those forums a lot myself but haven't come across a clear stating about these issues (apart from the SELinux shenanigans). So what about you flood us with your great wisdom instead big boy?
FlyingMachete said:
I saw you also sprayed ppl with their own bs on Blu spark thread. All i can say is I roam those forums a lot myself but haven't come across a clear stating about these issues (apart from the SELinux shenanigans). So what about you flood us with your great wisdom instead big boy?
Click to expand...
Click to collapse
Here you go:
Apparently you claim that you roam this forums and yet you didn't find the answer. Interesting claims.
Anyways here is your answer since even you didmt even fi d answer after roaming..
https://forum.xda-developers.com/showthread.php?t=3034811&page=5
Read it carefully though.. Explains why andriod OS drain battery more in first days (Not cycles) after flashing rom.. More apps, more the drain..
Tl;Dr for lazy people out there... Andriod os drain is present because Google itself has changed how andriod works..
On side note, I don't spread bs.. I just put my observations. It is upto people to fix it and accept the truth or get emo over it..
sarus_b said:
Here you go:
Apparently you claim that you roam this forums and yet you didn't find the answer. Interesting claims.
Anyways here is your answer since even you didmt even fi d answer after roaming..
https://forum.xda-developers.com/showthread.php?t=3034811&page=5
Read it carefully though.. Explains why andriod OS drain battery more in first days (Not cycles) after flashing rom.. More apps, more the drain..
Tl;Dr for lazy people out there... Andriod os drain is present because Google itself has changed how andriod works..
On side note, I don't spread bs.. I just put my observations. It is upto people to fix it and accept the truth or get emo over it..
Click to expand...
Click to collapse
I read this post from Rovo long ago, and I of course was taking about abnormal drains they were occurring long after reinstalls or new ROM flashes. It's well known, the rebuilding of caches etc.. Anyone complaining before this incompressible period should be treated like you do. Also, still thanx for minding sharing something at least and on a SECOND side note, read again, I never said you spread bs, pretty much the other way around, i was just suggesting you enlighten us instead of "spraying people with their own bs" like for example, on the Blu spark thread where I know you were putting whiners back in place. Cheers.
I am using magisk, so what about me?
Hi guys!
So I'm probably not as good with phones as you, but I learned to install a ROM, I've tried many of them but then returned to CyanogenMod ROM that was offered on their site. The performance is not that good, it lags often and battery life is too bad! The questions I want to ask you are:
1. Which ROM do you think is the most stable and would be a better alternative to Jelly Bean CyanogenMod?
2. What ROM are you using and why? Experiences etc.
Thank you!
Kind of in the same boat, just three meters further out. Have been putting off buying a new pho.... embiggened touch-pad device with phone capability and less battery life, that should in a reasonable world come with a carrying case with a shoulder-strap, and a stock portfolio for the handset maker... for a few years. But finally caved in, and bought something on sale with a really good screen, a replaceable battery, and a 3,5mm jack not made exclusively out of conductive rubber.
But. Now that I had a new phone pad, I wouldn't have to worry about bricking my old phone. All that much. So I went through a bunch of excruciating testing and failing yesterday to get something without ram-crippling bloatware and google applications that essentially force the 4x to run constantly at max speed.
What I seemed to be running into was two types of problems: a lot of the roms (custom firmware) were made by someone who was simply testing something new at the time, experimented a lot, and then left the project behind (or simply focused on other handsets). That's not necessarily a problem, but it can mean that you have stability issues you might not expect, and that has not been tested or reported while the project was active. And that might actually stop you from getting far enough to install some app that changes cpu-governor, ram-handling, and so on (even things like the standard keyboard/language variant.. kind of essential that that works). Install instructions also tend to link to outdated bootloaders, or have workaround suggestions that worked at the time, but now are obsoleted completely. The second problem was the OpenGapps - some of the core apps conflict with the builds' own apps.
And then there's the fact that the kernel in these roms tend to be from when the project was last maintained. I can't seem to decipher exactly what's going on, but I think a lot of the early roms were based on an old kernel with inserts (like the original one from LG). While the older builds on new kernel branches tend to have better support, but then have certain types of functionality simply gone completely. I don't know why that is, but the experience with this on linux laptops and android devices is what made me hold off until I had something that could replace the 4x before starting to try out some of the experiment builds people have.
So I went through getting the bootloader unlocked, trying a billion different methods before realizing they were all workarounds for the non-eu handsets - just use the oem-unlock method with fastboot. It's really as simple as it sounds. Use the "all in one" thing on the forum, set up the drivers, get root, and things like that - and then install a new, updated bootloader. I think after one of the official LG updates, everyone can actually use the oem-unlock.
Then I chose the wrong bootloader, apparently.. the cwm touch thing - superb bootloader. But apparently has some quirks that prevents it from installing certain firmware packages. I think it has something to do with consistency checking. I liked the idea of a multiboot, and didn't see why that wouldn't be extremely easy on android (with a storage size vs. cfw package being basically infinite to naught). But apparently what you want(need) is the twrp bootloader, and it has to be the last version. I don't know why that is, but you really don't want to be stuck - after basically wrecking your only boot - with an uninstallable image on your sdcard. So if you try something else than the "best one", just be prepared for an exit strategy with a backup and things like that before trying to install new images. There's also no way on these bootloaders to simply run a test first, nor is there a very easy way to partition the on-phone storage without having to start configuring install packages, so this is kind of awful if you're not actually deep into the development toolchains already.
I'd really love it if some of the tutorials said things like: our build really doesn't need a thorough wipe, and you can happily choose the file system you'd like, and the one that actually makes sense. For example. Or "for this cfw, you can just install gapps later on, that's going to work perfectly - don't force the install before you get through our own intro stage", etc. Alas.
Then I went through slimkat, an aosp lineage based rom, an old 4.1 rom, a new 5.1 rom, which all had different game-breaking problems. One refused to install gapps (note: you'll need the gapps that fit with the android version - but some packages simply won't install, period), another build had no sound other than on the speaker. One hanged randomly, another didn't scale the processor cores.
The good news is that this isn't really a problem - once you're set up you can just keep wiping and installing new ones. But it might be a really good idea to make a backup of your initial rom/custom firmware, just in case (i.e., you root, install the bootloader, and once you're in the bootloader, you make a backup of your current "rom" that is installed now. Then you can just revert to that without any problems later. I obviously didn't do that, because I was just fumbling around).
Some of the issues I ran into also might have workarounds, but I don't know - how would I, there's no way to actually tell what the problem is, or what it's related to. The most useful ones in the end seemed to be Vanir 6.0-based, and the one I ended up with, something called Euphoria on lollipop/5.1. That one seems to have all the hardware functions and benefitting a lot from a later kernel. I haven't done incredible amounts of testing on it yet, but it seems to work a lot better than the original firmware ever did.
And when you choose a gapps package, just go with the pico version. You can install everything you need after that from the store (and it takes less time than pre-installing the infinite amounts of crap in the stock package).
In sum - while you can get pretty far with the 4x on just rooting it and uninstalling some of the infinitely memory-hogging google crap, along with installing a new governor for the cpu and things like that. You can actually get something extremely neat by installing a new "rom"/cfw, that doesn't necessarily have the "oh, but you just have to forgo feature X, Y and Z because open source" problems.
I'm sure a cfw-developer is going to see this one day and roll their eyes back in their heads. And will have some very sharp words about the kind of effort that went into making a specific kernel, insert and build combination to even boot. But the later kernels seem to work really well.
And thanks to that Euphoria thing, I'm probably not going to use my new padphone-thing as much as I would. Because that one is over the "just testing stuff, getting it to work" stage. There's things with the home-button bar lighting up when there's notifications, things like that, that kind of show someone who used the handset was maintaining the build.
Anyway - I really recommend that you try out some different types to find these really good roms that works well. I'm sure there are lots of unknown cfw packages out there that work.. you know, for the 300 people who use it every day. That might be some of the early cfw variants with old kernels. And it might clearly also be some of the new ones, which I really didn't expect. Honestly, was kind of expecting stripes across the screen and hangs, but that didn't happen.
Optionally, a dev who actually knows what they're talking about could maybe suggest a list of cfw that have the later kernels that work, or the same kernels that Euphoria has Really, trying to search the net now, and find possible candidates was not easy.