Attend XDA's Second Annual Developer Conference, XDA:DevCon 2014!
5,781,962 Members 50,681 Now Online
XDA Developers Android and Mobile Development Forum
Announcement from MWisBest: Operation: Streamline.

[ROM][4.4.4/KTU84P][OMNIROM][LINARO/OPTIMIZED] FML: Fork My Life (07/05/2014)

Tip us?
(Last edited by MWisBest; 26th May 2014 at 10:01 PM.)
Senior Member - OP
Thanks Meter 1,837
Posts: 609
Join Date: Dec 2010
Location: Green Bay, WI

Default [ROM][4.4.4/KTU84P][OMNIROM][LINARO/OPTIMIZED] FML: Fork My Life (07/05/2014)

The Tale of FML.
In mid-August of 2013, I decided to set out to improve the performance of my phone with a more optimized build. I had already begun building CyanogenMod 10.2 shortly after all the repositories were updated on GitHub, so I just started forking stuff on GitHub to improve what I could... 42 forks later I finally had a build that finished, booted, etc. And since 42 is 'the answer to the ultimate question of life, the universe, and everything', and the amount of times I was saying FML during this process, I thought the name 'Fork My Life' would be (in?)appropriate. Now I've finally brought all of the optimizations I was doing with CM-10.2 to CM-11.0 as well, and more recently settled on OmniROM.

Why Should You Use FML? What's Different?!
To be honest, I don't necessarily care how many users or downloads my ROM has. What I do care about is people liking and enjoying their phone, if you try FML and you like it, great! I'm happy you enjoy it. If you don't, maybe leave some feedback on how I can improve it, and go try something else in the meantime. There are lots of ROMs to choose from, made by lots of talented developers, if you find something you like then I'm happy, regardless of whether or not it's FML. If you'd like to know what I've done that makes FML unique, here's a list:
- OmniROM base.*
- Highly optimized, similar to (and in some ways, better than) Linaro, resulting in a smoother and faster Android.*
- Attention to all the small details, along with always trying to be innovative and do something new and different.*
- Fully built with the latest GCC 4.8 toolchain from Linaro with C++11 enabled, yet a still-working ART runtime.***
- Also built with Link-Time Optimization for additional speed improvements.****
- Completely developed in the open, everything I do is right on my GitHub for anybody to use and improve upon.
- A somewhat-accurate ambient temperature sensor...*** (requires kernel support as well)
- A unique but stable kernel, includes 'BIGMEM' as well, adding back about 60MB of usable RAM.*
- Complete support for F2FS and EXT4, no 'conversions' required, and any combination of F2FS and EXT4 will work, not just 'one or the other.' Maybe you want F2FS on /data only, and EXT4 on /cache and /system? No problem!**
*: Something that not a lot of ROMs appear to do.
**: Something completely unique to FML, not done by anybody else (as of 2014/07/05).
***: Something that was done first by FML and later used by other developers for their users to enjoy as well!
****: Something done by very few ROMs, one or two at most.

Also available is a custom TWRP recovery image (separate download, not in the ROM itself). Notable changes/Improvements over official TWRP builds:
- Fixed decryption (was broken in, and under decrypted fine).
- Possibly improved speed. Most notable is the speed of decryption, other things are mostly limited by the speed of the eMMC instead though.
- Backlight brightness control.
- Fixed ADB (this change is actually in the ROM, so it effects ALL TWRP builds, not just this one).
- Completely seamless support of both EXT4 and F2FS.

Current Information
At this point I would consider the ROM to be a beta. This means that I don't endorse this ROM as a daily driver yet, however I do test builds before uploading them to make sure everything checks out OK. To many this is a fine daily driver but I do like to experiment and try new things, so you may find that you'll prefer an older build if it's more stable. So without further ado...

 * I am not responsible for bricked devices, dead SD cards, thermonuclear
 * war, or the current economic crisis caused by you following these
 * directions. YOU are choosing to make these modificiations, and
 * if you point your finger at me for messing up your device, I will
 * laugh at you.
I need people testing and finding bugs if anything is going to be fixed. I might not have the Bluetooth devices you have, I might not use the camera as much as you, I might not use 4G LTE (or mobile data in general really) as much as you; you get the idea.

1st FML Flash:
1. Do a backup in recovery and (optionally) backup apps with Titanium Backup or something similar.
2. Factory Reset in recovery (wipe data (NOT /SDCARD THOUGH), dalvik-cache, cache)
3. Wipe /system in recovery.
4. Flash ROM in recovery.
5. Flash GApps in recovery.
6. Reboot, and be patient. First boot takes a while.

Subsequent FML Flashes, unless otherwise instructed:
1. Do a backup in recovery and (optionally) backup apps with Titanium Backup or something similar.
2. Wipe /system, cache, and dalvik-cache in recovery.
3. Flash ROM in recovery.
4. Flash GApps in recovery.
5. Reboot, and be patient. First boot takes a while.
NOTE: You can probably get away with just wiping the 2 caches without wiping /system, however if any issues occur please re-test with a /system wipe.

Flashing the TWRP .img:
For this you can either use fastboot or the Flashify app, however I'm not going to delve into the details of that as it's really more deserving of a separate thread to fully explain.

Latest Build
XDA: (158.92 MB)
XDA: fml-twrp- (8.58 MB)
Dev-Host: (158.92 MB)
Dev-Host: fml-twrp- (8.58 MB)

I'm now recommending these GApps, thanks to PA for putting these together.
Personally, I'm using the 'Modular Mini' version, so if you have issues pertaining to GApps, please give that version a try.
Some GApps packages can be too large for DexOpting to /cache when using ART. As a result, I've added the option of enabling and disabling the 'DexOpt /system to /cache' feature. You can find this right next to the thing in Development Settings to change from/to Dalvik and ART. If you're using a larger, more fully-featured GApps package, and you want to use ART, make sure you uncheck this box before enabling ART. This setting should be persistent, meaning it will last between flashes, so you can just set it and forget it.
Soon I'll get an FML-specific GApps package going, because I haven't found a GApps package that contains a decent amount of stuff without breaking DexOpt /system to /cache.

Known Issues
- The screenrecord command does not work directly, however it does work via the Power menu.
- The "Long press back to kill app" option might not work on all apps.
- There can be a slight (noticeable, but not huge) delay when pressing the Recents or Home button.

Thank Yous
AOSP (and all its contributors), because without them we wouldn't have an Android like we do.
OmniROM (and all its contributors), because without them we wouldn't have the awesome bacon-topped AOSP they grill.
steven676 for helping the Galaxy Nexus community with some important KitKat fixes.
koush for the now go-to standard open-source Superuser.
ChainsDD for the original/classic Superuser and for serving our country.
Linaro (and all its contributors), they've done a good job of improving Android and with CM-11.0 I used some of their code.
metalspring for providing helpful code, advice, ideas, and just generally being a good person and developer.
DevVorteX for resolving most if not all of the issues with the VZW Galaxy Nexus RIL on Android versions 4.3 and higher.
Rushead for his long-time use and support of FML.
dbt816 for donating.
bothgoodandbad for donating.
rice923 for donating.
JD 11 for donating.
ulnevrwalkalone for donating.
sickboyy for donating.
Scott E. for donating.
Other donators who have (thus far) chosen to remain anonymous.
And anybody else I may have missed!
NOTE: I sent a PM/e-mail thanking any donor and asking for their permission to list their name here. Having their name listed is 'opt-in', meaning unless I explicitly receive a reply granting permission their name is not listed here.

I am now accepting donations. Previously I had felt that what I had done programming/code-wise with FML wasn't anything worthy of accepting donations as there's lots of people who could probably do that, however it has now come to a point where the time spent developing FML and the money I've spent on some hardware to help with developing FML is something that donations make sense for (along with some convincing from family and friends to accept donations).
To donate via PayPal, simply click the 'Donate To Me' button that appears on the left side of my posts.
UPDATE: If you can donate through Google Wallet, that would actually be better. PayPal takes some annoying fees with every donation, whereas Google Wallet does not. If you need help donating with Google Wallet, PM me and I'll guide you through it.

What the money received from donations will be used for is:
1. Hardware to help with FML development. Examples of what I have purchased for this are a nice internal Bluetooth 4.0 adapter to aid in testing and improving Bluetooth in FML, an MHL adapter, a USB OTG cable, micro USB cables (due to the locking mechanisms on them wearing out from constant use).
2. Saving for college. I'm not going to an expensive school, I'm being smart and trying to come out of college with as little debt as I can, e.x. currently I'm planning on starting out at a 2 year technical college, so even a little bit of money puts a good dent into costs.
3. Budgeting more time for FML. Let's be honest: money is a good motivator. It also helps to buy soda and snacks to give me the energy to keep going when I'm struggling figuring something out.
4. The cell phone bill. My dad has been extremely nice with paying for me to be on his plan for a number of years, and I'd like to be able to contribute towards the bill for once.
5. Whatever you would prefer. If you leave a note in the comment when donating stating how you'd like the money to be spent (e.x. '33% college, 33% cell bill, 33% soda/snacks') and I'll honor your request. You were nice enough to make a donation, the least I can do is spend it how you would most prefer.

XDA:DevDB Information
FML: Fork My Life, ROM for the Verizon Galaxy Nexus

ROM OS Version: 4.4.x KitKat
ROM Kernel: Linux 3.0.x
Based On: OmniROM

Version Information
Status: Beta

Created 2013-10-11
Last Updated 2014-07-05
Attached Thumbnails
Click image for larger version

Name:	Screenshot_2014-05-26-16-57-43.png
Views:	3050
Size:	243.2 KB
ID:	2764806   Click image for larger version

Name:	Screenshot_2014-05-26-17-07-41.png
Views:	2924
Size:	76.5 KB
ID:	2764825   Click image for larger version

Name:	Screenshot_2014-05-26-17-08-20.png
Views:	2771
Size:	68.5 KB
ID:	2764827   Click image for larger version

Name:	Screenshot_2014-05-26-17-08-29.png
Views:	2650
Size:	81.5 KB
ID:	2764828   Click image for larger version

Name:	Screenshot_2014-05-26-17-08-38.png
Views:	2422
Size:	79.8 KB
ID:	2764830  

Click image for larger version

Name:	Screenshot_2014-05-26-17-09-04.png
Views:	2417
Size:	97.9 KB
ID:	2764832  
VZW Galaxy Nexus (Current): FML-4.4.4
Kindle Fire HD 7" (Current): FML-4.4.4
LG Vortex (x2) (Retired): CM-9.0

FML (Fork My Life): VZW Galaxy Nexus (toro), GSM Galaxy Nexus (maguro)
The Following 78 Users Say Thank You to MWisBest For This Useful Post: [ Click to Expand ]
(Last edited by MWisBest; 5th July 2014 at 07:40 AM.)
Senior Member - OP
Thanks Meter 1,837
Posts: 609
Join Date: Dec 2010
Location: Green Bay, WI

Changelog, News, Etc.

2014/07/05 (Operation: Streamline)
ROM: Synced with OmniROM's latest changes as of around 6:30 AM 2014/07/05 UTC.
ROM/Build: Fully updated to AOSP 4.4.4 (specifically, the android-4.4.4_r1 tag), which really doesn't change much though...
ROM/Build: Stopped including the unused (as far as I can tell) dock.png in /system/vendor/res/images/dock/
ROM/Build: Leveraged a feature added to updater-script creation by OmniROM which coincidentally makes the ROM flashable on any format of /system partition, beit F2FS, EXT4, exFAT, whatever.
ROM/Build: Stopped including Voice Dialer. Voice Dialer is just an unpolished piece of junk which really isn't used ever since Google Now.
ROM/Build: Stopped including 0xBenchmark.
ROM/Core: A number of changes added for completely seamless and simultaneous F2FS and EXT4 support.
ROM/General: Switched to the Android KitKat boot animation, which takes up nearly 4MB less space than OmniROM's boot animation.
ROM/General: Used OptiPNG heavily on numerous things in an effort to save space.
ROM/Kernel: Added F2FS support, nearly 500 commits were merged in for this.
ROM/Kernel: Relaxed BIGMEM a bit to hopefully fix Camera crashing for some users. (Only a 4MB difference BTW)
ROM/Kernel: Optimized CPU L2 cache settings slightly.
TWRP: Added support for seamless and simultaneous F2FS and EXT4.

I'm forgetting a number of things and I'm not going into as much detail on some of this as I'd like to. Frankly, I'm exhausted. Maybe I'll expand on this tomorrow. Maybe.
Oh I also submitted 8 things to the OmniROM Gerrit. One has been merged so far, the others probably will probably be merged in the next day or two.

Older Builds:
2014/06/05 v2 (Operation: Chocoholic)
ROM: Synced with OmniROM's latest changes as of around 10:00 PM 2014/06/05 UTC.

V2 just fixes a bug where Dialer would crash upon entering the Call Log.

2014/06/05 (Operation: Chocoholic)
ROM: Synced with OmniROM's latest changes as of around 7:00 AM 2014/06/05 UTC.
ROM: Fully updated to AOSP 4.4.3 (specifically, the android-4.4.3_r1.1 tag).
ROM/Build: Removed some duplicate alarm and notification sounds in my never-ending effort to slim down the build size.
ROM/General: A few things were added to accommodate building for the Kindle Fire HD 7" that might spill over into the Galaxy Nexus builds (no harm, if anything an improvement).

Wanted to get an Android 4.4.3 build out ASAP, so this build doesn't have much in terms of changes/fixes from myself. This weekend I'll be going on vacation, and after I get back I'm planning on adding F2FS support finally.
BTW, you might want to make sure you have the 4.4.3 GApps.

2014/05/31 (Operation: Jackpot)
ROM: Synced with OmniROM's latest changes as of around 11:30 PM 2014/05/31 UTC.
ROM/ART: Pulled in some things from AOSP's master branch to hopefully decrease initial boot-up time for ART.
ROM/Build: Fixed some more instances of code being compiled/optimized for a generic ARM CPU instead of the Cortex-A9 specifically.
ROM/Build: Included some requested translations.
ROM/Build: Found a fix by PrimeDirective to build frameworks/base/core with -fstrict-aliasing.
ROM/Dalvik: Pulled in some things from AOSP's master branch to increase overall speed for Dalvik.
ROM/General: Fixed a bug where overclocking would revert when the screen was turned off.
ROM/General: Added battery charging LED support.
ROM/General: Fixed notification LED flash interval being way too long by default.
ROM/General: Experimental improvements for GPS. (See: GitHub Commit)
ROM/Kernel: Added the "purple tint fix" commit.
ROM/Settings: Fixed Settings not being translated.

Quite the changelog here! ART is feeling a little snappier in this build but Dalvik might still be faster!

2014/05/26 (Operation: Speed Racer)
ROM: Synced with OmniROM's latest changes as of around 7:00 AM 2014/05/26 UTC.
ROM/Build: Improvements to LTO.
ROM/Build: Fixed a potential issue where LTO wouldn't provide any benefits.
ROM/Build: Fixed a bug where the compiler was optimizing towards a generic ARMv7 CPU instead of a Cortex-A9 CPU.
ROM/Build: Fixed a couple small things that were overriding the -O3 flag with -O2.

Uhh... this build is ****ing fast. I noticed the speed improvement before even flashing the ROM: decryption in the TWRP build was at least 5x faster. After flashing and rebooting, I saw the same improvements in decryption... there's a little animation that plays when decryption is running, and it's so fast that the animation isn't even animated, it's just a quick little still image. It's just ridiculous how fast this build is.

2014/05/10 (Operation: Preparation)
ROM: Synced with OmniROM's latest changes as of around 11:00 PM 2014/05/10 UTC.
ROM: Updated (mk)sh to R48. (Small thing most people won't notice)
ROM: Small bugfix/update for oprofile. (Small thing most people won't notice)
ROM: Some behind-the-scenes stuff to help make sure the next (overly ambitious) FML build goes smooth.

Nothing much here, just figured I'd get a synced up build out now before I end up not being able to because I'm working on some bigger changes for FML.

2014/04/29 (Operation: Exterminator)
ROM: Synced with OmniROM's latest changes as of around 4:00 PM 2014/04/29 UTC.
ROM/ScreenRecord: Fixed ScreenRecord crashing instantly.
ROM: Tried tweaking things to reduce battery consumption regression that popped up in the 2014/04/12 build.
ROM/Audio: Thanks to syncing with OmniROM, the distortion that sometimes occurred in audio playback is fixed.
ROM/GPS: Blind attempt at improving GPS lock-on speed, probably didn't work but I can't tell yet.
ROM: Miscellaneous improvements and bug fixes that will probably go unnoticed.

Not a lot of exciting stuff here, but I figured I'd get this build out with the various bug fixes that accumulated since the last one.
BTW, the issue with ScreenRecord was that it attempted to record the phone's audio directly (the audio it outputs through headphones/speaker), which has issues with at the very least the Galaxy Nexus if not all non-Qualcomm hardware. I had to switch it so that it records the phone's microphone instead.

2014/04/12 (Operation: Flyswatter)
ROM: Synced with OmniROM's latest changes as of around 7:00 AM 2014/04/12 UTC.
ROM: Re-added multi-core DexOpting (speeds up the first boot after a dalvik-cache wipe), OmniROM removed this as it caused problems for some people it seems, but it's working just fine over here on FML.
ROM/OmniTorch: Fixed FC when attempting to create a Torch widget.
ROM/DSPManager: Fixed an aliasing violation (due to a recent change to DSPManager which was courtesy of CyanogenMod -.-).
ROM/ART+Dalvik+Settings Added an option in Development Settings to toggle the "DexOpt /system to /cache" feature due to it having a few possible but rare issues.

Blaaahhh. Sorry this build took so long, it's just after I noticed OmniROM removed the multi-core DexOpting I had to add it back due to how long an initial bootup with ART and 150 apps was taking (it seemed like an entire hour honestly), and then once I figured that all out I ended up having one last bug to fix with the new toggle I added for DexOpt /system to /cache. I didn't want to release something that I didn't feel was good enough!

2014/04/02 (Operation: Buzzkill)
ROM: Synced with OmniROM's latest changes as of around 11:00 PM 2014/04/02 UTC.
ROM: Removed some stuff I didn't feel was necessary to include (some ugly live wallpapers, the video editor, the "Dev Tools" app).
ROM: Removed OpenDelta (OmniROM's updater).
ROM/RIL: Fixed issues when using the Quick Settings tile to switch between 4G/LTE and 3G/CDMA. For the past 4 or 5 builds, using this toggle would make mobile data not work whatsoever. Also, the toggle used to think there was 3 different data settings ("2G Only", "2G/3G Preferred", "4G/LTE"), now it's only 2 and correctly described ("3G/CDMA, "4G/LTE").
ROM/ART: Merged in some stuff from AOSP's master branch of ART. This is kind of experimental, there might be some issues with some apps, if so let me know.
ROM/ART+Dalvik: Make apps in /system store their dalvik-cache on the /cache partition. Previously the /cache partition just sat there, all ~500MB of it empty. A side-effect of this is that when using ART, you have to use a smaller GApps package, as when using ART the dalvik-cache takes up more space, and with the full GApps packages it's too much. If you're using the larger GApps because you're concerned about saving space on the /data partition, if you just install the full GApps stuff via the Play Store (therefore storing the apk on /data), you're still saving space due to all the space freed up via making using the /cache partition.
TWRP-Recovery: Now building and uploading TWRP recovery images as well. Current improvements over official TWRP builds: Added backlight control, fixed decryption of encrypted /data partition.
ROM/Recovery: Fixed MTP (access to internal storage via USB) and ADB not working in TWRP (shouldn't require usage of my TWRP build, just the ROM should be sufficient).

Please make sure to read the note about ART and GApps. This build is part of "Operation: Buzzkill", attempting to find and squash as many bugs as possible.

ROM: Synced with OmniROM's latest changes as of around 7:30 AM 2014/03/22 UTC.
ROM: Added 0xBenchmark. Details below.
ROM/OmniTorch: Fixed "Bright" option showing up even though it isn't available. Known Issue: OmniTorch widgets are broken.
ROM/PhaseBeam: Fixed PhaseBeam Live Wallpaper causing extreme lag.
ROM/RIL: Merged in more fixes courtesy of @DevVorteX

Since I wasn't able to do the big stuff I wanted I figured I'd do a bunch of small stuff so it feels like I got a decent amount of things accomplished.

As for 0xBench, this is something I stumbled across in Linaro's git repo. Figured I'd give it a shot. Play around with it, feel free to share what results you're getting with it and at what kernel settings (overclock, specific kernel if non-stock, etc).

ROM: Synced with OmniROM's latest changes as of around 12:30 AM 2014/03/10 UTC.

No changes other than the sync with this build, the next build should have some cool new stuff though.

ROM: Synced with OmniROM's latest changes as of around 12:00 AM 2014/02/26 UTC.
ROM/RIL: Added code from @DevVorteX to improve mobile data stability.

Well I'm about a day late with this one, better than weeks though.
BTW today is my birthday ^.^

ROM: Synced with OmniROM's latest changes as of around 12:30 AM 2014/02/22 UTC.
Build: Re-enabled LTO.
Build/Toolchain: Linaro toolchains updated.

Didn't do huge changes with this build since I want to make sure that if there's any issues, I can know that it's probably due to LTO and then just simply disable LTO in problem areas.

ROM: Synced with OmniROM's latest changes as of around 6:00 PM 2014/02/01 UTC.
Build: Fixed issues with repo after git updated to 1.9.rc1 (apparently repo wasn't fond of having rc1 in the git version number!)

Navbar customization is in this build, along with OmniSwitch!

I'm still busy with school unfortunately.
The reason I had more time for FML before the holidays was that I didn't really have my priorities straight. School had began taking a back seat to things like FML and video games etc. Since then I've rectified that, as school should really be my #1 priority, but now dev work has ended up where schoolwork was before. It's not easy finding a balance between work and fun, but I think I'm getting there!

ROM: Synced with OmniROM's latest changes as of around 4:00 AM 2014/01/25 UTC.
ROM: Miscellaneous fixes to get it building after some of OmniROM's latest changes.
Build: Linaro toolchain was updated, I think.

Not a lot of stuff with this build, I've been pretty busy lately and haven't had a lot of time to devote to FML. Things are looking better now, so hopefully I'll have the time to do more frequent builds and such. I'm looking into possibly having a computer running 24/7 that'll do nightly or bi-nightly builds of FML, I just need to see if it'll have trouble with the specs of the computer I'd have to use for it and figure out how to manage automatically merging in OmniROM's changes.

ROM: Synced with OmniROM's latest changes as of around 12:00 AM 2014/01/15 UTC.
Kernel: Redid all the work done for the New Year's build in hopes of fixing the screen freezing problem.

Put a lot of time into this. Please let me know if the screen still freezes.
Voltages are a bit higher than they were with the New Year's kernel, so battery life will probably be slightly worse, but that can be tweaked for the next build. The priority was fixing the lock-ups.

ROM: Synced with OmniROM's latest changes as of around 4:15 AM 2014/01/09 UTC.

Just synced up with the latest OmniROM code in this build, and also the toolchains were updated since the last build. There were some reverts of things in OmniROM that required me to use a bit of tinkering with git to get everything merged correctly.
Apologies for the lack of updates lately, I've been busy with life and -40*F/-40*C (-40 is where the two scales intersect lmao) wind chills.

ROM: Synced with OmniROM's latest changes as of around 6:00 PM 2014/01/01 UTC.
ROM/Settings: Fixed force closing when attempting to use WiFi Tethering.
ROM/Settings: Fixed not being able to turn LTE on again after turning it off.
ROM/Keyboard: Added the necessary lib to support gesture typing out-of-the-box.
Kernel: Pulled in a lot of bells and whistles. You can view lots of them by going into Settings --> Performance.

I'd appreciate it if you'd give the kernel a try before flashing a different one, I put a lot of work into this last night. I'll try and leave more details as to what's all there soon.

ROM: Switched to OmniROM as the ROM base.
ROM/Build: Didn't build with Link-Time Optimization just yet, and a few other miscellaneous FML sprinkles are still missing.
ROM/Settings: Added built-in Superuser as OmniROM didn't have it, so flashing SuperSU is not required nor recommended.

You'll need to wipe /data before flashing this build, it's basically like flashing a new ROM. Back up everything of course.

ROM: Selectively synced with CM's latest changes as of around 4:30 AM 2013/12/21 UTC.
ROM/Build: Enabled Link-Time Optimization.
ROM/Build: Fixed every aliasing violation except in frameworks/opt/net/voip and external/openssh, allowing for further optimizing.

Make sure you wipe /system too before flashing this one, regardless of which FML build you're coming from. This is a little experimental still, but it seems good enough to release now considering I still don't endorse this ROM as a major daily driver lol.

ROM: Synced with CM's latest changes as of around 4:30 AM 2013/12/15 UTC.
ROM/RIL: SMS/MMS should be fixed on new flashes. (via CM sync)
ROM/RIL: Fixed connection to 3G after turning off WiFi. (via CM sync, slightly "expedited" if you get what I'm saying...)
ROM/Hardware: Small possible speed-up brought back from the previous CM-10.2 FML Linaro/Optimized builds.

If you're having issues with SMS/MMS still, go to Apps and clear the data of Phone/Messaging Storage, then reboot. If that still doesn't fix it, please let me know.
I didn't get a chance to look closer at the Handcent FCing issue, but it might be fixed via the CM sync, so don't be afraid to give it another try.

ROM: Synced with CM's latest changes as of around 8:00 PM 2013/12/13 UTC.
ROM/Build: Switched to Linaro's GCC 4.8 toolchain.
ROM/Build: Optimized compiler flags to speed things up, along with changes to tons of Android code to not derp out with them.
ROM/ART: Build ART using the Clang/LLVM compiler instead of GCC, as it has been reported that it has issues with GCC 4.8.

In many ways I am now ahead of Linaro when it comes to Android 4.4. With Android 4.3, they built it using C++11, which provides some more speed and fixes etc. With Android 4.4, they aren't doing this (yet?), and I don't know if they're using GCC 4.8 yet either.
Due to the changes I had to make with ART, there might be some issues that weren't there before. So far everything seems OK, but if you run into issues please send me a logcat.

IMPORTANT: If you are currently using ART, please switch to Dalvik before flashing. After flashing the new build, you can then re-enable ART.

ROM: Synced with CM's latest changes as of around 12:15 AM 2013/12/05 UTC.
Kernel: Enabled Fast Charge by default.

Didn't change a whole lot with this build, but I wanted to get a new build synced up with CM out now in case what I'm planning on doing next takes longer than I think it will. BTW, if you're concerned about Fast Charge being enabled by default, you can just disable it before you plug into a computer if you want.

ROM: Synced with CM's latest changes as of around 1:00 AM 2013/12/02 UTC.
ROM: Added a couple possible fixes for wakelock issues with old (really really really old) radios. Just a shot in the dark here.
Kernel: Added Fast Charge that requires no user interaction (thanks @joshua_).

For Fast Charge you don't have to do anything: Just plug the phone in, no messing with sysfs interfaces or anything like that. It'll still say "Charging (USB)" under the Battery menu, but it should charge as fast as your USB port will allow (up to the phone's own 1A limit).

CM added a lot of stuff recently, it's looking a LOT like CM 10.2 did finally. Go in the Settings menu and mess around! ART is working fine for me, please let me know if you're still having issues.

ROM: Synced with CM's latest changes as of around 2:00 PM 2013/11/25 UTC.
ROM: Fixed graphical glitches with CRT-Off and screen rotation animations.
Kernel: Added imoseyon's fix for the random MAC address bug.
Kernel: Couple misc fixes that probably won't be noticed, but the perfectionist in me just had to do them.

I lied, this build is very exciting!

Honestly, the GPU isn't 100% fixed: There's still the issue of the animation that plays when a screenshot is taken being completely distorted, but the final result is fine and it doesn't impair use and user experience like the CRT-Off and rotation animations did. I'm sure that will be fixed soon enough, and it can be called "101% fixed" then.

ROM: Synced with CM's latest changes as of around 6:00 AM 2013/11/21 UTC.
ROM: Added a fix to allow toggling between LTE and 3G, this should be working just like JellyBean now.
ROM: Added a fix to get rid of the black boxes in the stock browser and in things using the stock browser's rendering engine.


ROM: Switched to CyanogenMod 11.0 for the base, instead of pure AOSP.
Kernel: Using CM's kernel as screen freezes are reported to not be happening anymore in it.
ROM/Kernel: Added temperature sensor changes again.
Kernel: Added boype's adjusted RAM timings, gives about 10% more throughput in RAM.
Kernel: Added TUNA_BIGMEM config option and enabled it by default for the moment, adds a good 60MB+ usable RAM.
ROM/Build: Restored some of the FML changes from CM-10.2, more will be added over time.

Alright, CM's repos seemed to have beem calming down after the crapstorm that was KitKat, so I've decided to go ahead and give it a try again. I myself did a data wipe as well when flashing from AOSP-based FML, it might not be required, YMMV.
Also, enabling and disabling LTE should work alright now and not cause you to lose out on getting an LTE connection altogether. You may notice the options under Mobile Networks will always say 3G, but if you pop open the menu the choices are the 4.3.x and below usual LTE and 3G only instead of the mess KitKat made.

ROM: Updated Superuser to work with the ART compiler.
ROM: Switched to android-4.4_r1.1 tag, build ID now KRT16O.
ROM: Made lockscreen status bar and navigation bar transparent.

Just a small update, nothing big, but the ART compiler is amazingly fast and I'd recommend giving it a shot (you will need the updated GApps linked in the OP though). I'm going to work on the kernel later today as well.

ROM: init.d support.
ROM: Possible mobile data improvements, I'll let you be the judge of it though.
ROM: Switched to using Launcher3 instead of Launcher2 (looks more like the Google Home launcher).
ROM/Kernel: Added an init.d script to hopefully help reduce screen freezes.
ROM/Build: Slimmed down the build by about 17MB by removing some useless junk.

The init.d script I added will do the following:
- Set the maximum CPU frequency to 1228MHz (upped from 1200MHz, 1200MHz isn't even a mapped frequency in Fancy Kernel).
- Set the minimum CPU frequency to 384MHz (upped from 192MHz).
- Set the minimum Screen On CPU frequency to 537MHz (upped from 192MHz, it wasn't being set at all!).
- Set the maximum Screen Off CPU frequency to 729MHz (upped from 192MHz, it wasn't being set at all!).
- Set the GPU frequency to 384MHz (upped from 307MHz).
- Do some other misc. tweaks that Fancy Kernel did with its RAMdisk scripts and whatnot.

All-in-all this should help to stop the screen freezes. If not, I might start upping the default voltages for the CPU frequencies, as in my opinion the screen freezing is being caused by a voltage starvation of sorts.

ROM: Managed to implement one of the two surprises I wanted to, you'll see it right away!
ROM: Small attempt at a data improvement, albeit unsuccessful (no adverse side-effects however).
Build: Preparations to get a different kernel going.

ROM: Now including Superuser, built-in to the Settings app like CyanogenMod.
ROM: Now including busybox as well.
Kernel: Tweaks to improve stability, notably to eliminate the issue of the screen just completely freezing.
Build: Misc. tweaks, mostly little nitpicks of mine that probably won't be noticed by others anyways.

If you were using SuperSU, please before flashing this open up SuperSU and find the thing in the options to clean-up and remove it completely. I'd also like you to format /system for this flash if you don't already. If any issues come up with root, not doing this will probably be the reason why.
I haven't forgotten about other things, I just haven't had the time to get them done yet. Tomorrow should be better! Planning on: TWRP build compatible with 4.4 ROMs, data fixes, and two surprises...

2013/11/04 v2
ROM: GPS and Camera fixed.
Build: Changed model number from "AOSP on Toro" to "Galaxy Nexus".

Finally tracked down what was wrong with the Camera and as a result even fixed the GPS.

Build: Enabled in-line kernel building, now building Fancy Kernel right into the ROM.
Kernel: Updated to Linux 3.0.101.

The Gallery app seems to work in this release, however the camera is still having issues.
I would've preferred to get the camera working before releasing this, but I wanted to get a new build out today as well and time ran a little short.

ROM: First AOSP 4.4 build.

This is about as bone-stock as AOSP gets... I don't even have a custom kernel in here right now. I'll be working on this more later tonight.

Slim down the build by putting less used stock applications into a separate flashable .zip, such as Browser.

Experiments I'm Looking Into
Creating Black Holes with my phone's ridiculously awesome speed.
The Following 23 Users Say Thank You to MWisBest For This Useful Post: [ Click to Expand ]
(Last edited by MWisBest; 29th May 2014 at 05:22 PM.)
Senior Member - OP
Thanks Meter 1,837
Posts: 609
Join Date: Dec 2010
Location: Green Bay, WI

Developer Info
This is a little section I'm gonna set up explaining things in more technicalish and "down-and-dirty" details of sorts for developers interested in this project and potentially incorporating it into their projects.

The only thing I ask is to make a little "Thank You" section in your main post like I have here and credit at least me and Linaro, and also credit anybody else's work I have used if you use it as well. I'd also appreciate it if you could maybe link my name to this thread or my user profile here on XDA, but that part isn't a requirement.

All of my work can be found on my GitHub. Please note that any commits on my GitHub that are after the most recent build of FML should be considered experimental and potentially not working at all. I develop on the fly and often times things on my GitHub aren't finished and fully tested unless they have made their way into an official build of FML.
Please pay no attention to where it says a repository was forked from. Often times I'll have forks that I just re-use to avoid duplicate and unnecessary extra repos. For example, in repos forked from CyanogenMod you might notice the default branch is actually something like "omni-4.4" indicating that branch is based from OmniROM and not CyanogenMod.
The best place to keep track of what parts of the Android source code that needs patches is the manifest.

All About Strict Aliasing!
One of the big things Linaro does with improving Android's performance is fixing violations of what's known as "the strict aliasing rule."
A pointer is said to alias another pointer when they both refer to the same location of memory. This is OK and not an uncommon thing to do. The strict aliasing rule is that pointers of different types should never refer to the same location of memory (aka alias each other). Things like this are just fine and dandy:
void pointlessFunction( uint32_t foo )
    uint32_t* const bar = (uint32_t*)&foo;
That's alright, as foo and bar are the same type. Note that it's also OK if the only difference between foo and bar is signedness (e.x. uint32_t and int32_t).
Now this...
void anotherPointlessFunction( uint32_t foo )
    uint16_t* const bar = (uint16_t*)&foo;
...this is a problem. foo and bar are NOT the same type. This is a violation of strict aliasing.
Strict aliasing allows a compiler to make some assumptions when compiling and optimizing code that it otherwise couldn't. This is a good read about the benefits of it.
Here's a few examples of fixing strict aliasing violations:
Note that not everything is fixable, or worth fixing. Sometimes you'll just have to add -fno-strict-aliasing to the problematic section and call it a day:

Of Unicorns and Compilers...
This section will delve into compilers and flags for them. The "Of Unicorns" part is in reference to the amount of false information, misconceptions, and mythical beliefs regarding these things. One thing in particular is the common belief that throwing every flag possible at the compiler results in better/faster binaries. That couldn't be further from the truth, and is something that actually took me quite some time to properly understand myself (in part because the misconceptions are more common than the actual truth!). In this section I will mainly be referencing the GCC compiler, as that's what is currently used for the majority of Android and most Linux systems as a whole. The other compiler that is making quite a run at GCC is Clang, so first I will talk about GCC vs Clang quickly:

GCC vs. Clang
GCC is currently (~May 2014) the most common compiler used for Linux and Linux-based systems (which includes Android). GCC was first released in 1987, as the "GNU C Compiler." Not long after its release, it was extended to support C++ as well, and over time many different languages and platforms became supported by GCC so it is now called the "GNU Compiler Collection." Over all this time, GCC became more and more difficult to maintain. As time passes on, fewer and fewer people have been able to get their foot in the door to work on GCC as it just became so... bloated.
Eventually, somebody finally got the guts (or resources, rather) to take on GCC and make a competing compiler. Clang was born.
Clang is a front-end for LLVM. Initially, LLVM was going to make use of GCC's front-end for making a C/C++/etc. compiler using LLVM's back-end, however this was just too cumbersome of a task due to GCC's difficult-to-work-with codebase, which was what sparked Clang instead.
Fun fact: Clang 1.0 was released in 2009. It was first open-sourced in 2007. That's 20 years after GCC's inception, but yet Clang has managed to tear GCC's usage apart. However to be fair, LLVM's initial release was 2003, but that's still a decade and a half head-start given to GCC!

As of GCC 4.8 vs. LLVM/Clang 3.4, it's kind of a toss-up between the two. In some cases GCC has better binary results and in other cases Clang has better binary results, however Clang outshines GCC in areas other than the resulting compiled code:
1. Clang is faster and uses fewer resources than GCC when compiling. It's usually a safe bet that Clang is going to be at least 50% (1.5x) faster than GCC when compiling, whilst also somehow using less RAM and disk space than GCC. For those of you that like being eco-friendly, just imagine the amount of energy this saves!
2. Clang has generally been ahead-of-the-game when it comes to supporting C++ standards. Current example: Clang has been C++14 feature-complete since the end of 2013, while GCC (even in 4.9!) is not.

Thanks to the competition from Clang, GCC has also been stepping up its game as well too. All-in-all this has been a win-win for everybody so far.

Aaand here we go on compiler flags. For this I'll be referencing the GCC documentation on "GCC command options", here:
Of particular interest in this section will be "Options That Control Optimization", but other sections are often overlooked which can be of use, I'll explain those later though.

The first thing you'll see in the "Options That Control Optimization" section are the -O options. These are general optimization levels that give you a sensible default to work with.
First off is -O0. This is the default, and doesn't turn on any optimization options. This is generally only used for debugging code, as some optimizations can interfere with that.
Next would be -O1. This enables some optimizations to reduce code size and improve speed, without increasing the time it takes to compile code significantly.
After that is -O2. This is what is generally used for most program compiling, as it enables plenty of optimizations and these ones generally don't cause problems/bugs with the resulting binaries whilst greatly improving speed.
Then there are some non-numbered ones which I'll go over:
-Os is somewhere between -O1 and -O2. It enables most of -O2's options, but disables some that can increase the size of the resulting binaries. This can be of great use when dealing with smaller embedded systems where space is generally preferred over speed. It's closer to -O2 than -O1...
-Og is useful for debugging purposes. It enables a few optimizations that generally don't effect ability to debug code, so devs don't have to deal with the slowness of -O0 as much as usual.
And then there's the almighty -O3...
-O3 enables some extra optimizations that -O2 does not. The drawbacks are increased compile time, increased binary size, and the possibility for some bugs. In many cases, -O3 might not improve speed over -O2 whatsoever. In other cases it can be helpful, but it is nothing compared to the differences between -O1 and -O2.
Android generally uses -O2 by default. It's safe and fast enough for most cases. -Os is also used for any Thumb instruction-set code for ARM, as Thumb is generally meant for reduced size and complexity from what I can tell.
There's also a flag kinda above -O3, which is -Ofast. The problem with -Ofast is that it can cause huge problems for any code that makes the (correct!) assumption about some math stuff, so it is generally avoided.

Then there are some flags that aren't enabled by any optimization level. This is not without reason: these flags are, generally, useless. They increase compile time by a ridiculous amount, and their effects on the resulting binaries might be absolutely nothing. Zilch. Nadda. Even for something as large as Android, these flags can still do nothing. If these flags can have a speed-up, it's generally not without risk, and they should be kept to specific use-cases rather than used on every single thing.
These flags can be considered about the equivalent of using the "placebo" profile for h264 video encoding. It has a less-than 1% improvement in the resulting quality, yet can take twice as long to render (or, in this case, compile). And they are pretty much exactly what the placebo profile for h264 encoding is, a placebo effect. You will not find a measurable increase in speed, and the risks associated with it are generally not worth it!

There is an exception to that though: -flto. This enables Link-Time Optimization, and can have huge impacts on both the speed of the binaries as well as even a reduction in their size! LTO can be viewed as this: when the compiler is truckin along compiling things, it generally only sees bits and pieces of the project at hand. LTO allows the compiler to view how everything works together rather than just each individual part, and in doing so it can find HUGE improvements! When LTO was in its infancy with GCC, it was pretty unstable, but with GCC 4.8 and above it can be used reliably. It's also advised to use the -fuse-linker-plugin flag when using LTO as well (read the docs on that).
Here is my work on using LTO with Android, it's more involved than simply adding it with all the other flags which is why you'll generally hear the people that are making use of the "unicorn flags" say it doesn't work...
Ignore the things in the last couple commits there that aren't related to LTO...
But like I said, it's more involved than just throwing the flags blindly at the compiler, there are a few other fixes required to get a successful build with LTO:
And then it also has to be disabled in ART, that fix courtesy of @metalspring :

// To be continued.

Small but Helpful Things
I thought I'd put some simple little things here that can be immensely helpful to devs. Most of these they'll probably know already, but some won't and when I learned these things they had a profound impact on development. At the very least it can be a helpful reminder/reference sort of thing.
Properly Logging Builds
This is something I finally figured out not long ago that has had a huge impact on debugging problems...
I'm not all that great with bash but I generally understood redirecting the output of a program to a file. However, when I tried the usual:
make -jX otapackage > buildlog.txt
, not everything was going to the file. Eventually I learned that just using ">" only redirects stdout, and not stderr which was where all the warnings and errors went to. To get around that, there's a couple options. One, you can redirect stdout and stderr to separate files, like so:
make -jX otapackage 1> buildstdout.txt 2> buildstderr.txt
, or the other option is to just lump them all into a single file using:
make -jX otapackage > buildlog.txt 2>&1

This post is a WIP...
The Following 5 Users Say Thank You to MWisBest For This Useful Post: [ Click to Expand ]
(Last edited by MWisBest; 13th December 2013 at 08:56 PM.)
Senior Member - OP
Thanks Meter 1,837
Posts: 609
Join Date: Dec 2010
Location: Green Bay, WI

Default Reserved

The Following 6 Users Say Thank You to MWisBest For This Useful Post: [ Click to Expand ]
Enter The Nexus
Enter The Nexus's Avatar
Senior Member
Thanks Meter 200
Posts: 489
Join Date: Oct 2012
Location: Trapped in BasedWorld

> XDABEBB's 2.0 VS98025A

ASUS MeMO Pad Smart ME301T
> OmniRom 4.4.4
The Following User Says Thank You to Enter The Nexus For This Useful Post: [ Click to Expand ]
Senior Member - OP
Thanks Meter 1,837
Posts: 609
Join Date: Dec 2010
Location: Green Bay, WI

Originally Posted by Enter The Nexus View Post
I plan on finishing up the thread when I wake up. I've pretty much pulled an all-nighter and need to get some rest, especially after the night I had at work (I was literally doing the jobs of 2 other people and nearly quit!). It really doesn't look any different than just a stock CM 10.2 build, I don't think I've really changed anything with the interface (yet, anyway).

So, expect screens in maybe 10 hours or so.
VZW Galaxy Nexus (Current): FML-4.4.4
Kindle Fire HD 7" (Current): FML-4.4.4
LG Vortex (x2) (Retired): CM-9.0

FML (Fork My Life): VZW Galaxy Nexus (toro), GSM Galaxy Nexus (maguro)
The Following 5 Users Say Thank You to MWisBest For This Useful Post: [ Click to Expand ]
Multisupermono's Avatar
Senior Member
Thanks Meter 62
Posts: 170
Join Date: May 2013
Location: Austin TX
Flashing this now! It looks pretty awesome!
The Following User Says Thank You to Multisupermono For This Useful Post: [ Click to Expand ]
Senior Member - OP
Thanks Meter 1,837
Posts: 609
Join Date: Dec 2010
Location: Green Bay, WI

Originally Posted by Multisupermono View Post
Flashing this now! It looks pretty awesome!
Thanks! I appreciate your interest in my ROM.

I'm going to be doing a fresh build right now and then I'll get up some screenshots. Should be a couple hours or so.
VZW Galaxy Nexus (Current): FML-4.4.4
Kindle Fire HD 7" (Current): FML-4.4.4
LG Vortex (x2) (Retired): CM-9.0

FML (Fork My Life): VZW Galaxy Nexus (toro), GSM Galaxy Nexus (maguro)
The Following 3 Users Say Thank You to MWisBest For This Useful Post: [ Click to Expand ]
nitsua98's Avatar
Senior Member
Thanks Meter 941
Posts: 1,826
Join Date: Jul 2012
Location: Dallas, Texas
Looks cool, I'm must wondering if the MMS/no phone # bug is fixed yet.
"We the unwilling led by the unqualified to kill the unfortunate die for the ungrateful."
The Following User Says Thank You to nitsua98 For This Useful Post: [ Click to Expand ]
(Last edited by MWisBest; 31st August 2013 at 08:46 PM.)
Senior Member - OP
Thanks Meter 1,837
Posts: 609
Join Date: Dec 2010
Location: Green Bay, WI

Originally Posted by nitsua98 View Post
Looks cool, I'm must wondering if the MMS/no phone # bug is fixed yet.
I'm not quite sure what you mean by that. MMS has worked fine for me and so have phone calls. Was this pertaining to my ROM or another one?

EDIT: By the way, build is taking a little longer than I thought it would, not quite sure where it's at yet. I'll give an update on the progress in the next hour or so. Also, I have to wait 2 minutes to make and/or edit a post, it says I need a "reasonable post count" before that timer goes down; I also had wanted to post this on the DevDB as when I posted the topic it told me I should, however I couldn't find where to do that. I presume I have to be a "Recognized Developer" or something before it'll let me. If anybody knows the post count I need to remove the 2 minute timer and/or how to be a Recognized Developer, please let me know!
VZW Galaxy Nexus (Current): FML-4.4.4
Kindle Fire HD 7" (Current): FML-4.4.4
LG Vortex (x2) (Retired): CM-9.0

FML (Fork My Life): VZW Galaxy Nexus (toro), GSM Galaxy Nexus (maguro)

The Following User Says Thank You to MWisBest For This Useful Post: [ Click to Expand ]
aosp, linaro, omnirom, optimized, toro
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes