[ROM][5.0.2/LRX22G][AOSP][LINARO/OPTIMIZED] FML: Fork My Life (2015/01/08)
[#Intro]
Oh, and now there's these Lollipops I'm handing out. They are free as always, and they are very very delicious.
[#Why]
[#Info]
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.
[#HowTo]
Latest BuildKitKat/ROM Stable: omni-4.4.4-20140705-toro-FML.zip (158.92 MB)
KitKat/TWRP Stable: fml-twrp-2.7.1.0-20140705-toro.img (8.58 MB)
KitKat/ROM Beta: omni-4.4.4-20141014-toro-FML.zip (160.87 MB)
Lollipop/ROM Beta: FML-AOSP-5.0-20150108-toro.zip (195.43 MB)
LOLLIPOP INFO:
USE THESE GAPPS: FML-GApps-5.0.x-20150101-tuna.zip (167.81 MB)
They are based on PA's GApps, huge thank you to them!
Known Issues
- Camera can be a little touchy, but it generally works.
Lollipop Changelogs can be found in the post below!
(KitKat) BETA INFO:
Beta builds are using updated GPU drivers (and an updated kernel to go with them) courtesy of @Ziyan, as well as being up to date with the latest stuff from OmniROM. NOTE: YOU CANNOT FLASH A DIFFERENT KERNEL WITH THESE BUILDS.
Currently broken with the new GPU drivers:
- Hardware Video Decoding FIXED 2014/10/06
- Hardware Video Encoding(?) FIXED 2014/10/08
- Camera (PARTIALLY) FIXED 2014/10/08
- The stock camera app (as well as Google Camera) has this weird quirk of crashing when pressing the shutter button to take a picture, however many different camera apps on the Play Store (in particular Camera ZOOM FX) work flawlessly. Video recording is generally OK, however I've been getting some reports of the audio and video being a little out of sync, so your mileage may vary...
See the Changelog post below for..... well..... changelogs.
[#GApps]
Known Issues- The screenrecord command does not work directly, however it does work via the Power menu.
- There can be a slight (noticeable, but not huge) delay when pressing the Recents or Home button.
[#Thanks]
[#Donations]
XDA:DevDB Information
FML: Fork My Life, ROM for the Verizon Galaxy Nexus
Contributors
MWisBest
Source Code: https://github.com/MWisBest/
ROM OS Version: 5.0.x Lollipop
ROM Kernel: Linux 3.0.x
Based On: AOSP
Version Information
Status: Beta
Stable Release Date: 2014-07-05
Beta Release Date: 2015-01-08
Created 2013-10-11
Last Updated 2015-01-08
Changelog, News, Etc.
Lollipop Beta Changelogs:
2015/01/08
- Updated the camera HAL.
This is going to be a little... fragile, at first, but in the long run it's needed. Stock camera app saves pictures now at least.
You may also notice that there's a 5.1MP resolution now (clear your camera app's data if you don't see it), despite our camera supposedly being 5.0MP all these years. Turns out the sensor's native resolution is indeed a whopping 16 pixels taller and 16 pixels wider than we've been using.
2015/01/04
- Added back some of the classic FML optimizations and more.
Built with -fstrict-aliasing flag, C++11, and the Linaro GCC 4.9 toolchain.
- Updated to AOSP "android-5.0.2_r1" tag.
As usual, the only real change was them bumping the version number.
- Improved flashing.
The speed of flashing the ROM zip is now much faster.
- Superuser is now built-in.
There's no need to flash SuperSU. You can find Superuser in the Settings app. You may have to enable the "Development Settings" menu to see it.
Some apps are a little sketchy with this Superuser though, most notably Titanium Backup. If you have issues, try flashing SuperSU.
- Video playback should be fixed.
YouTube in particular seems OK. If you have some weird format you're playing back locally I cannot make any guarantees though.
- The camera situation has improved and also regressed.
The stock camera is kinda back to the point of where it was with the KitKat Beta builds:
---- Preview works. Saving photos does not work. Video recording kinda works.
--- However:
---- The camera calibration is a little messed up. Long story, but it'll be fixed soon. So your white balance may look kinda funky, among other things.
- Audio quality is improved, with support for 192kHz FLAC as well.
This is possible thanks to a new audio resampler, which doesn't impose the same sample rate restrictions of the stock Android ones. It also has far better quality than the stock Android resamplers.
- WiiMotes can now be paired via Bluetooth.
I used to be a bit of a Wii hacking enthusiast... I think I still need to add some more stuff to make it useable as a gamepad or something, but yeah.
- Fixed location services issues.
- (toro) Fixed switching between 4G/LTE and 3G/CDMA network settings.
- Kernel changes:
Reclaimed 38MB of RAM from the carveout stuff.
Removed HDMI's framebuffer, saving an additional ~16MB of RAM. With Lollipop, MHL/HDMI out isn't working with our old HWComposer, so might as well save some RAM in the mean time.
Added overclocking support, as well as adjusted the stock frequencies a little.
Added the GPU kernel driver back into the kernel, rather than building it as a separate module.
Switched to LZO compression for the kernel. It results in a slightly larger size to the kernel, but it boots faster.
Added the "purple tint fix".
Added compiler flag to tune code for Cortex-A9 CPU.
Built with Linaro GCC 4.9 toolchain.
Older Builds:
2014/11/16
- Fixed the RIL.
There were a few things that went into this, and I can't really take much credit for it other than being persistent in trying to fix it.
1. rild needed a little fix-up to somewhat return it to pre-Lollipop form. Basically Google is forcing Qualcomm's junk upon the world. @dhiru1602 pointed me in the direction of some commits from rmcc to hardware/ril that fixed this part of the problem.
2. The kernel needed a commit to support some new junk related to networking in Lollipop. @Ziyan linked me to the change in question.
3. toro's RIL was trying to add a route to the table with a netmask of 255.255.255.255, which isn't correct and won't fly with Lollipop anymore I guess. @Hashcode was the one to point out that this was an issue and helped me figure out that the netmask was a string in the RIL blob that I could edit freely, and after some brainstorming with dhiru1602 I was able to stick in the right netmask of 255.255.255.000.
- Updated to AOSP "android-5.0.0_r6" tag.
Really the only change is that the build number is bumped to LRX21T.
- Switched out a couple small proprietary binaries with a reverse-engineered open-source version.
Thanks to @stargo who has really been killin' it for the Motorola OMAP devices recently, we now have a reverse-engineered pvrsrvinit binary (the executable that fires up the GPU drivers on boot-up). This is especially important because the proprietary pvrsrvinit wasn't compiled as PIE (position-independent executable). With Lollipop, they're forcing everything to be PIE, which is good because PIE is better from a security stand-point. Previously I had been adding a workaround to enable support for non-PIE, which I now don't need.
- Built the ROM with "WITH_DEXPREOPT" set to true.
This basically just adds the ".odex" files to /system. With ART this is important because it cuts down on those lengthy boot-up times because instead of compiling the apps' code on the device, it now compiles it on my computer when I build the ROM instead.
- Changed the "Android is upgrading..." screen to prevent burn-in.
Rather than use Lollipop's eye-hurting bright white theme on this screen, I've switched it back to the classic, darker theme.
2014/11/09
- Switched back to the old OTA package format.
With Lollipop they're now, by default, flashing something similar to a system.img. I switched back to the old format. THIS IS CAUSING VERY LENGTHY FLASH TIMES NOW HOWEVER, I HOPE TO FIX THESE SOON.
- Changed the kernel to build with GCC 4.7.
With Lollipop, Google switched to GCC 4.8. GCC 4.8 has never been kind to the Galaxy Nexus kernel, I'm surprised it was booting at all in the first place.
- Added "Ambient Display".
Apparently I need to add a "pick-up" or "significant motion" sensor for it though, so it displays something when the phone is picked up.
- Fixed chromium crashing.
This fixes Browser crashing upon open, among other things. This fix has been in chromium itself for nearly 4 months now, I don't know what the heck Google is doing to AOSP to make it so FUBAR lately...
- Fixed lag in Recents menu.
Now it's smoother than KitKat's, in my opinion.
- Added back F2FS support.
F2FS is now supported again, HOWEVER, it is NOT supported on the /system partition. It really didn't do any good for /system anyway.
- Updated various icons.
The Dialer icon in particular was bothering me. Other things that aren't visible in the launcher, e.g. SettingsProvider, have been fixed as well.
- Fixed FLAC playback, among other media decoding issues.
Just needed a sync-up in the device tree with one thing that I think Google DID do a nice job of with Lollipop actually.
KitKat Beta Changelogs:
2014/10/15
- Cleaned up the kernel.
Ziyan went over all his work not long ago and cleaned up the commit history and whatnot. He's letting me do the task of merging in the GPU driver stuff, so I'm currently just getting the kernel to a "clean slate" of sorts for other kernel devs to fork and build off of. Basically this should hopefully be the new "stock" or "Google" kernel. As a result, there's some bells and whistles missing from this build. It does however include some new audio updates that weren't in the previous kernel, which leads me to this...
- Changed audio sampling rate to 48kHz.
Previously the sampling rate has been 44.1kHz. The Galaxy Nexus supports 48kHz though! Here's what mainly sparked this change: since KitKat, the UI audio effects (e.x. touch sounds) have been switching over to 48kHz. With the Galaxy Nexus still using 44.1kHz, UI sound playback became kinda sluggish, and this was a big contributor to it. The UI sounds use the "fast track" audio path (where it tries to do as little processing as it can to the audio in order to play it with a minimum amount of latency), however a requirement of using this is that no resampling (e.g. converting 48kHz to 44.1kHz, like it has been doing currently with KitKat) can be required on the audio being played. Therefore the UI sounds were taking the "deep buffer" audio path, which has a delay to it. In switching to 48kHz, the "fast track" path is actually even faster now than it has ever been previously, and the Galaxy Nexus was already TOP OF THE LINE when it comes to audio latency believe it or not!
Another thing about this is that there is now support for playback of 96kHz audio files.
- Some updates to the camera HAL.
This hasn't fixed the situation of stock and stock-based camera apps crashing when taking a picture, but it's a start on it though.
NOTICE: Poweramp (and probably most other media players that use their own native code for audio playback rather than straight-up using the built-in Android APIs) is being pissy about the sampling rate change. If you experience issues with music playing, especially things like popping or crackling, please try Play Music or Apollo and see if your issue is still present. I know the UIs for Play Music and Apollo are pretty awful, but I can't write my own media player because I'm dealing with this camera stuff!
KitKat Stable Changelogs:
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. :good:
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.
2014/03/22
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).
2014/03/10
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.
2014/02/26
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 ^.^
2014/02/22
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.
2014/02/01
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!
2014/01/25
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.
2014/01/15
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.
2014/01/09
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.
2014/01/01
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.
2013/12/30
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.
2013/12/21
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.
2013/12/15
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.
To-Do.Slim down the build by putting less used stock applications into a separate flashable .zip, such as Browser.
Experiments I'm Looking IntoCreating Black Holes with my phone's ridiculously awesome speed.
Developer InfoThis 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:
Code:
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...
Code:
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:
DSPManager
frameworks/av
bionic
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:
frameworks/base
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.
Flags.
Aaand here we go on compiler flags. For this I'll be referencing the GCC documentation on "GCC command options", here: https://gcc.gnu.org/onlinedocs/gcc/index.html#toc_Invoking-GCC
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...
https://github.com/MWisBest/android_build/commit/c1b041c32572b6ee1bbb17b1fa8c038c5e9fde1f
https://github.com/MWisBest/android_build/commit/95bb49b613424b70af3e820748724fb92ef35b5e
https://github.com/MWisBest/android_build/commit/d2c13f1c35cfa9c114a69c74cfb1c2631643eebc
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:
https://github.com/MWisBest/android_bionic/commit/3b3f59a173a7cc4ff3a1cec4456a99108ce08092
And then it also has to be disabled in ART, that fix courtesy of @metalspring : https://github.com/MWisBest/android_art/commit/9ed3774fcba75077e098720406d261b79bd9baa9
// To be continued.
Small but Helpful ThingsI 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:
Code:
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:
Code:
make -jX otapackage 1> buildstdout.txt 2> buildstderr.txt
, or the other option is to just lump them all into a single file using:
Code:
make -jX otapackage > buildlog.txt 2>&1
This post is a WIP...
Reserved
Reserved.
Screens?
Enter The Nexus said:
Screens?
Click to expand...
Click to collapse
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.
Flashing this now! It looks pretty awesome!
Multisupermono said:
Flashing this now! It looks pretty awesome!
Click to expand...
Click to collapse
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.
Looks cool, I'm must wondering if the MMS/no phone # bug is fixed yet.
nitsua98 said:
Looks cool, I'm must wondering if the MMS/no phone # bug is fixed yet.
Click to expand...
Click to collapse
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!
MWisBest said:
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?
Click to expand...
Click to collapse
CyanogrnMod has had a bug recently where your phone number says 'unknown' and something is messed with the prl. I guess in your build it's already merged. Could you check to see if you're phone number is down in About Phone>Status? Thanks
nitsua98 said:
CyanogrnMod has had a bug recently where your phone number says 'unknown' and something is messed with the prl. I guess in your build it's already merged. Could you check to see if you're phone number is down in About Phone>Status? Thanks
Click to expand...
Click to collapse
Last night I did have to reboot my phone as it was stuck on "Searching For Service" for some odd reason and it said I was "Out of Service" in About Phone, but my phone number was still there and still is. I'm guessing I either already merged in the fix or maybe I just merged in the bug, I'll have to check! Thanks for the heads up.
EDIT: It looks like it's related to the most recent 3 commits merged here: http://review.cyanogenmod.org/#/q/s...nogenMod/android_frameworks_opt_telephony,n,z
I do a repo sync before I do a build, so it looks like I pulled those in before I did the build last night. Should be good to go!
EDIT2: Today's build should be finishing up shortly. Most future builds should be faster than this one, once in a while (once per week maybe?) I like to start with a fresh build rather than just an incremental one. Incremental builds just rebuild what's needed based on what code has changed, however it isn't perfect; a fresh build ends up rebuilding everything from scratch. Once the build finishes I'll give it a quick test and then upload it along with some screenshots.
New build looks good, check out the 2nd post for the changelog. Currently uploading the build and screenshots and will update the 1st post accordingly.
EDIT: Alright, uploaded and good-to-go! I'm heading off to work but I'll try to drop in on the thread for any support during my break.
EDIT2: I got a (mobile network) connectivity issue I found that I'm attempting to debug right now, it doesn't happen often and I don't know what triggers it but a reboot seems to fix it until it happens again. So, if you're having a connectivity issue try rebooting to fix it for now.
EDIT3: It looks like there's some changes to AOSP's master (latest) branch that may help not only fix this issue but data connectivity issues as a whole (handoff delays, etc.) I'll be experimenting with them and will post an update if something works out.
New build will be up shortly, mobile network connectivity appears to be much improved! I'm still going to look more into this as I, correct me if I'm wrong, believe it's something not only affecting FML but also other 4.3 ROMs for the Verizon Galaxy Nexus (toro).
EDIT: 1st and 2nd posts updated with new build and changelog for said build, give it a whirl while I get some much needed sleep! I appreciate everybody's interest and feedback, honestly I was just expecting nobody to even look at it and for it to just fall back to the last page of the forum really. I suppose if you set your expectations that low, anything is a win!
Running this now. So far so good.
Sent from my Galaxy Nexus using Tapatalk 4
modernbummer said:
Running this now. So far so good.
Sent from my Galaxy Nexus using Tapatalk 4
Click to expand...
Click to collapse
Me as well. MMS works as supposed.Data seems to be working better than regular CM builds.
modernbummer said:
Running this now. So far so good.
Sent from my Galaxy Nexus using Tapatalk 4
Click to expand...
Click to collapse
christianpeso said:
Me as well. MMS works as supposed.Data seems to be working better than regular CM builds.
Click to expand...
Click to collapse
Great! Glad to hear everything is working OK, thanks for the feedback.
EDIT: Quick update on mobile connectivity here... it looks like what might have been causing the data issue where I had to reboot the other night was tracked down in CM. This is the change proposed to revert a change that was apparently causing issues on the Verizon Galaxy S3 similar to what I described: http://review.cyanogenmod.org/#/c/48873/
I'm going to wait to see if this happens again, and if so incorporate that change to see if it fixes it, just in case I might have fixed it with that AOSP merge last night.
EDIT2: Hit the issue again, had to reboot to fix it. I'm going to be reverting that change that supposedly caused this issue and upload a new build with it, however I have to head off to work shortly so it won't be until later tonight unfortunately. Sorry for the inconvenience! If a reboot doesn't fix it a reflash supposedly does, it would only require wiping /system, /cache, and dalvik-cache, so you could leave the /data folder alone to keep your apps and settings and whatnot, just simply reflashing the ROM then (and GApps too, as /system is wiped!).
Love it so far. An option to center status bar clock would be nice. Also I love custom carrier labels because I hate Verizon haha so I wouldn't mind seeing that available
Also, is there a reason you can't just wipe the two caches when updating? I just ask because most ROMs are that way.
swarlesbarkely said:
Love it so far. An option to center status bar clock would be nice. Also I love custom carrier labels because I hate Verizon haha so I wouldn't mind seeing that available
Also, is there a reason you can't just wipe the two caches when updating? I just ask because most ROMs are that way.
Click to expand...
Click to collapse
Thanks! I appreciate the feedback and will look into adding the centered status bar clock and custom carrier label. I remember those from previous CM versions and liked it as well.
While wiping the two caches would probably work, I just prefer a full /system wipe because if any files are renamed/moved/deleted they'll still have the old crust left behind which could lead to problems. The /system partition shouldn't really have to be messed with anyways; if there is something you customize in there yourself you can let me know and I'll see what I can do about incorporating it.
In short, you can wipe just the 2 caches and flash, however if you run into an issue after doing that I'd prefer that you test it again with a /system wipe as well.
BTW, I just got home from work, very long night... I'm gonna get a build with the hopeful fix for mobile data issues up and then probably call it a night.
New build is up! Check out the changelog and flash away.
I also made a note in the OP of the only wiping the 2 caches thing that swarles mentioned above.
EDIT: Yikes, looks like I just ran into yet another issue with mobile data. I'll keep a link in the OP to the build from yesterday in-case others have the same issue while I try to sort it out.
EDIT2: I may have discovered a big reason for why we Verizon Galaxy Nexus users have had mobile data issues with 4.3, I'll do some more investigating and if what I've discovered is correct I will share what I can with the community here. :fingers-crossed:
Related
FRX07.1 is here!!
This is a maintenance release - basically taking the newest components to make a completely up-to-date (as of Sept. 1).
Quite a lot has changed since FRX06 - the install process hasn't really, but be sure to read the changelog in the next post and the caveats in post #3!
<<<This is a link to the... FAQ Click it!!>>>
I have created a complete bundle of FroYo with a stable kernel from GIT (August 19 / 1348), and rootfs from GIT (Sept. 2).
Please, feel free to DONATE to the XDAndroid project!
Every little bit helps!
Directions:
1. Download the full bundle (zip). (Updated September 1 2011)
If instead you just want the system.ext2 (zip) (Updated July 15 2011) file by itself... Don't download this if you're not sure! Grab the full bundle!
2. Extract it. You’ll see a folder, FRX07.1, copy its contents to the root of your SD card. If you want to run Android from a folder instead of all the files on the root of the card, follow the steps below.
3. Go into the STARTUPS folder. Grab the appropriate startup.txt for your device (if you don't know what device you have, you should read the FAQ), and move it to the root of the card (or where you run haret.exe from. If you want to change the location of the build, put a rel_path= statement in the cmdline section of the startup.txt. Mine is located two folders deep on the SD, so my rel_path=Androids/TP2Ref)
4. Screen calibration - you have three choices:
Re-use an old ts-calibration file if you have it and you know it's good.
Download the ts-calibration.zip file and extract it to where you put the rest of the files (root of SD or in a folder - make sure it all stays together!)
Manually calibrate - boot with no ts-calibration file and watch the boot process - you'll be asked to hit 5 points to calibrate the screen. If you have issues calibrating, try an older kernel (1225 works well) Once you have the calibration file hold on to it (make 15 copies if it's a good one ), reboot & go back to the newest kernel!
6. Run haret.exe.. Profit!
Let it settle out on the first boot. Many have reported they had to reboot basically because it was so slow - if you let it sit for about 10 mins so the media scanner can go thru everything, etc. it will be much more pleasurable experience. If you want adb in and watch the processes via top, you'll see why the phone seems so slow - there's lots of background processes cranking because this is the first boot .
Troubleshooting:
Please read the... FAQ
If you have any issues with the kernel, feel free to change it:
There are some devices that are having issues with the newest kernels. Please see the kernel autobuild service to get archived kernels. Once you download a replacement kernel, go to where you run haret.exe from - remove your old zImage/modules-xxxxx.tar.gz. Take the new zImage/modules-xxxxx.tar.gz and replace the old ones, same folder - where you run haret.exe from. Make sure the ‘zImage’ is named just that. Do not rename the modules file, do not extract it - should be in .tar.gz format.
See Incremental Updates for more information on updating the kernel and other components.
Random issues can often be solved by forcing the system to create a new data.img. If you're worried about losing data (all user data is stored in the data.img!!), Titanium Backup works quite well. If you wish, you can rename the data.img to something else, and let the system create a new one - just to see if it resolves your problem.
Similarly, if you wish try formatting your SD card - I prefer to use the HP Tool - do a full format, FAT32.
Even though this build is considered fairly stable, you are more than likely going to run into issues. The next post will address issues particular to this build - PLEASE READ THESE before asking questions! Feel free to post questions in this thread, I will do my best to address them. Big thanks to stinebd for releasing the system image, and of course the other developers for their hard work on making these kernels available.
stinebd's Changelog:
stinebd said:
Here’s a new release for you, folks. This is a major release with a ton of changes, new features, and fixes. Our friend hyc/highlandsun did most of the heavy lifting for this release. Highlights include a rewritten RIL with support for world phones and greatly improved CDMA support; fixes for the media codecs; fixes for MMS on Sprint; increased security with the Superuser app.
A list of changes is included below. The FRX07 system image is available for download now, and will require the use of a new rootfs image, also available now. Additionally, we have a new bundle containing everything needed to enjoy a full FRX07 system.
Note: Due to the incredibly long list of changes, this is a somewhat condensed, terse changelog describing only the overall scope of the changes.
FRX07:
frameworks/base:
Major frameworks changes for CDMA/GSM dual-mode worldphone support. (hyc)
Fixes for data connection handling to improve startup time. (hyc)
Fixes for wifi handling to avoid issues on hanged drivers. (hyc)
Stagefreight (media codecs) fixes. (hyc/viruscrazy)
Fixes for Sprint’s wonky MMS markup structure. (hyc)
Fix MediaScanner not finding audio files (including ringtones) in system.ext2
hardware/libhardware_legacy:
Minor GPS driver fixes. (Alex[sp3dev])
Rename wifi interfaces to wlan0 on all devices (hyc)
hardware/xdandroid-ril: Major RIL refactoring for improved performance on all devices, and added CDMA/GSM dual-mode worldphone support. (hyc)
packages/apps/Gallery3D: Switched back to Gallery3D as the gallery app (closes bug #111)
packages/apps/Mms: Fixes for Sprint’s wonky MMS markup structure. (hyc)
packages/apps/Phone: Fixes for CDMA/GSM dual-mode worldphone support. (hyc)
packages/apps/Superuser: Added the Superuser package for authorizing su privileges. This, along with our signed builds, provides greatly increased security for the end user (mostly against malicious apps from the Market).
system/extras/su: Added as a dependency for the Superuser package
vendor/qcom/android-open: Include missing stagefright codec symbols. (hyc/viruscrazy)
To coincide with the FRX07 system image, the following rootfs changes have been made:
init.froyo.rc modifications...
Adjust wpa_supplicant service for the new abstraction provided by libhardware_legacy, as well as interface rename
Abstract the hciattach service to provide bluetooth support on both chipsets
Rename wifi interface to wlan0 on all devices
apns-conf.xml updated
keymaps completely reorganized, and RHOD end-call key has been remapped to be the Home key in Android.
default.prop: set ro.secure=1 to lock down the adb shell - su can be used with the Superuser app to authorize root access in adb if needed.
Click to expand...
Click to collapse
Layman's Changelog
(As in, the changelog I wrote )
FRX07.1 Changelog:
RHOD - all buttons on the front no longer wake the device. Only the power button wakes the device now.
Updated to the newest RIL
hyc's modified libs for video now baked in - *most* HQ YouTube videos (and other HQ videos) should finally work!
RHOD & TOPA - Userland (Android) now controls the LED by default now. If you need to debug sleep, you will have to change the behavior manually. See Detule's post on this topic.
Facebook sync should now work, out-of-box.
FRX07 Changelog:
Updated RIL (thanks hyc!) - this covers many different bugs that were in the old RIL - I'm only going to cover the major ones...
CDMA now works correctly (for the most part). force_cdma (and north_am_dialing) is now deprecated (not needed/ignored!)
You can boot with a SIM in on a CDMA device and choose your GSM or CDMA on the fly under Settings.
Location based on towers now works on CDMA.
1xRTT now displays correctly, but I never seem to get EVDO Rev.a... I always get 0. This is represented by a 3g icon, as this is what the Android framework provides.
Full MMS support! Please see this page for configuration instructions. Will need help fleshing out the list of carriers folks!
Spotty service, switching towers, etc should no longer cause the dreaded SoD (Sleep of Death) condition!
(Basic audio) 3.5mm support for RHOD400/500
Droidwall works out of the box now
Keyboard backlight now fades in/out
Gallery3D back in! Picasa Web Sync comes with it
A couple new apps added to AndroidApps folder:
rpierce99's app GetLogs
Titanium Backup
Caveats:
BT - works now! But audio doesn't route. See this thread if you're feeling adventurous and want to play with/don't mind using some unstable/incomplete code...
NOTE: BT must be disabled in WinMo before booting Android or else you'll run into all sorts of odd issues...
WEP on wifi doesn't work. I heard an app called 'wifi-ace' (on the Market) fixes WEP!
If auto-brightness is enabled, the keyboard/button lights will fail at random. See this post for more scant details .
Yay! No more "when is FRX07 coming out?" posts!
highlandsun said:
Yay! No more "when is FRX07 coming out?" posts!
Click to expand...
Click to collapse
And to that effect, I would like to personally apologize to everyone for how long it took. Life has been crazy busy the past couple months. Hopefully we'll get GRX01 out in a more timely manner.
Woooohooooo!!! Thanks to all of the dev's on this, Stine, Hyc, Emwe, Arrrghhh (for putting up with all the BS!), and anyone else involved.
Can't wait to try this out. Thanks to all who contributed =)
highlandsun said:
Yay! No more "when is FRX07 coming out?" posts!
Click to expand...
Click to collapse
Just to get a sense of things, is it too soon for a "when is FRX08 coming out" post?
Diam 500 endlessly repeats smd-tty buffer mismatch on first boot (same as last 2? Kernels). Thanks for your work on this aargh and xda team.
Sent from my LG-P999 using Tapatalk
bluenote73 said:
Diam 500 endlessly repeats smd-tty buffer mismatch on first boot (same as last 2? Kernels). Thanks for your work on this aargh and xda team.
Sent from my LG-P999 using Tapatalk
Click to expand...
Click to collapse
Ah yea... I need to test this on a RAPH800 I just got my hands on, thanks for reminding me!
Quick question. Prior to right now I've been running Hyc's 5/30 build very successfully and very happily. With that build, sound was working when recording a video. With the new FRX07, no sound comes when recording a video. Any ideas on how to get the sound to work with recording video on FRX07?
wmg316 said:
Quick question. Prior to right now I've been running Hyc's 5/30 build very successfully and very happily. With that build, sound was working when recording a video. With the new FRX07, no sound comes when recording a video. Any ideas on how to get the sound to work with recording video on FRX07?
Click to expand...
Click to collapse
His build has the new acoustic code seen here. It routes audio in a much better fashion, for sure... but it's not stable. Still needs some work, so it's not in FRX07...
arrrghhh said:
His build has the new acoustic code seen here. It routes audio in a much better fashion, for sure... but it's not stable. Still needs some work, so it's not in FRX07...
Click to expand...
Click to collapse
Thank you sir!
Big thanks to every one on the dev team for FRX07. You guys are awesome.
Just extracted FRX07 on to a newly formatted sdcard, copied startup & calib from FRX06 and when I launch haret, i get the following error.
"Error reading file. Expected 4096 got 0"
Anyone know what it means? Search did not turn up many useful hits.
webxplore said:
Big thanks to every one on the dev team for FRX07. You guys are awesome.
Just extracted FRX07 on to a newly formatted sdcard, copied startup & calib from FRX06 and when I launch haret, i get the following error.
"Error reading file. Expected 4096 got 0"
Anyone know what it means? Search did not turn up many useful hits.
Click to expand...
Click to collapse
Figured out...Had a corrupt zimage file. Able to launch now.
After a few hours of testing, great job!
The battery status actually tracks really close to where windows mobile says it should be. It also seems to go to sleep, and stay sleeping!
The only thing that's keeping me from using it full time is the phone and speaker phone have noticeable static that windows mobile doesn't have. Does the beta audio routing fix this, or are there some new settings I can try?
I also love the recent apps on end long press, fancy
First Impressions
Coming from FroyoB Hercules, this is a step up in my opinion. A HUGE step up.
I am running the Tilt2 with a 2GB Class 2 SD card and the provided FRX07 package .zip.
The build is running smooth and silky (making me have more faith in looped builds heh heh) with slight overclocking (633.600MHz). Had one hot reboot while accessing the Notification bar at the same time Market was updating Google apps, but after that the updates proceeded without issue. Everything else has yet to be tested, but I'm sure I won't run into anything major.
I'm 110% satisfied running the build. Accessing menus is quick and not laggy at all. To me, that's what's important: user functionality. You guys nailed it big time, and for that I thank you all very much. I won't be using CWM for a looong while
EDIT: Figured I'd list what is and isn't working for me. Again, I'm using all the default components like kernel and whatnot on the Tilt2 and have the phone overclocked to 710.400MHz now:
WiFi - Works
Data - Works (most stable I've experienced)
Bluetooth - Works (haven't tried headset)
WiFi HotSpot - Buggy; Turns on, but disabling keeps the notification icon and enabling again causes reboot. Different kernel doesn't fix.
USB Tethering - Works/Turns On (Don't have the driver to test quite yet )
Camera/Camcorder - Works (Camcorder doesn't record sound.. known issue?)
Phone - Works flawlessly
MMS - Incoming/Outgoing Works
maff1989 said:
Coming from FroyoB Hercules, this is a step up in my opinion. A HUGE step up.
I am running the Tilt2 with a 2GB Class 2 SD card and the provided FRX07 package .zip.
The build is running smooth and silky (making me have more faith in looped builds heh heh) with slight overclocking (633.600MHz). Had one hot reboot while accessing the Notification bar at the same time Market was updating Google apps, but after that the updates proceeded without issue. Everything else has yet to be tested, but I'm sure I won't run into anything major.
I'm 110% satisfied running the build. Accessing menus is quick and not laggy at all. To me, that's what's important: user functionality. You guys nailed it big time, and for that I thank you all very much. I won't be using CWM for a looong while
Click to expand...
Click to collapse
+1
Come from FroyoB Hercules v2.
Any possible to run FRX07 on CWM?
FRX07 on cwm is being worked on by Eodun,wich sadly yesterday released FRX06 for cwm
rtrip said:
After a few hours of testing, great job!
The battery status actually tracks really close to where windows mobile says it should be. It also seems to go to sleep, and stay sleeping!
The only thing that's keeping me from using it full time is the phone and speaker phone have noticeable static that windows mobile doesn't have. Does the beta audio routing fix this, or are there some new settings I can try?
I also love the recent apps on end long press, fancy
Click to expand...
Click to collapse
I would bet that the new audio routing stuff fixes the static problems. It definitely cleaned things up for me. But at this point I think we need a newer kernel in addition to the new audio libraries, the stuff in that audio routing thread is rather out of date at the moment.
I've been running most of this stuff for more than a month without issues. It's definitely going to be a lot more solid than any previous builds...
Hello all!
I wish to present to you a source built AOKP, as I saw we only had a port so far.
This isn't meant to knock the port, I just like source built things. So now people may use their preference in a ROM.
So far I haven't seen any issues, but if you find any please let me know!
I will be adding features and such to this once I get the inkling that I want them, but for now, AOKP goodness!
Credits:
AOKP Team for the epic ROM, of course.
CyanogenMod Team for their device tree, which I've modded heavily.
TheUnkn0wn for his wonderful camera, with lots of options.
TheMuppets for their always up-to-date device blobs.
Google for Android. <3
GideonX for his BMS Kernel.
And all of my users, for keeping me working hard at squashing bugs!
DOWNLOAD Build 11/03:
http://d-h.st/NQy
Mirror, courtesy of paulg1981:
https://dl.dumptruck.goldenfrog.com/p/Zo2YMWuFcm/aokp_d2spr_unofficial_Mar-10-13.zip?dl=1
Always assume that dirty flashing this ROM is unsafe. You can do it, but if you get force closes or other such issues don't bother reporting it until you have done a FULL wipe. This means /system, /data, /cache and dalvik-cache, and then installed the ROM fresh. If you do report bugs on a dirty flash, I'll ignore them and tell you to do a full wipe.
Latest Changelog: March 11th, 0945 EST.
Code:
March 11th
Lockscreen Rewrite WIP incorporated from Steve Spear
Bitmap optimizations
Better thumbnail handling
Tried to fix tile update logic
Breathing SMS notification. Ees pretty.
OLD
Code:
March 8th
Lockscreen targets are removed for now, code was all busted.
MMS is fixed. The first will fail, the rest will work. WiFi is tempermental.
More optimization for our CPU.
Linaro compiled the entire ROM.
Got permission from [url=http://forum.xda-developers.com/member.php?u=2645480]GideonX[/url] to use his [url=http://forum.xda-developers.com/showthread.php?t=2134894]epic BMS kernel.[/url]
Fixed some gremlins in the system that were causing crashes en masse.
AOKP Mainline sync'd and up-to-date as of March 8th.
Reverted Camera back to default, added storage selection.
This fixes FFC crashing, but if you still want TheUnkn0wn's cam it will break FFC again.
Switched to open source Superuser by Koushik Dutta. SU options are located in System settings.
First boot PerformanceControl may crash, this is due to an init script line that
I had to place in to limit the CPU clock on first start; otherwise it will boot at 1.836 GHz.
If you wish to remove this limit, it is located in /system/etc/init.qcom.post_boot.sh
PerformanceControl is executed after init scripts, so if you set something there it will override this
(if apply on boot is selected)
February 16
Lockscreen targets are back.
Snuck in some a9 optimization
re-applied all of my previous fixes.
Updated to 4.2.2 base.
GCC 4.7 -O3 compiled (linaro soon...ish)
Fixed Roaming (i think, can't test on modded PRL.)
Kanged TeamBAKED for their keyboard.
and i'm pretty sure i got all the little gremlins causing issues.. let me know.
February 8
Re-did the entire build directory.
AOKP-Tracked kernel (Credits to BMC08GT)
Tweaked system, now with more bang.
Re-did optimizations, added more from a friend.
Hardware back to kill is moved into ROMControl again, as it should be.
Fast charge toggle fixed.
Possibly fixed charging LED (maybe, don't yell at me, but it works here.)
A2DP now works without borking headphones (kernel level, bmc08gt)
Added swipe to quicksettings.
January 26
Changed up some stuff in the system to provide stability.
Fixed hardware back to kill function.
Note: the function has moved to the very bottom of developer settings.
Performance control updated to repo version, and now it won't be in the app drawer!
It's moved to the settings.
Chronus now has options, it's in the app drawer.
I did fiddle with a couple things for the RIL, so if there's a signal boost it's entirely by chance.
January 21
Sync'd up with AOKP mainline.
added TheUnkn0wn's camera, head over to his thread [url=http://forum.xda-developers.com/showthread.php?t=1746611]here[/url] and thank him.
Lockscreen wallpapers are back!
There's lots more, but unfortunately I don't remember them all right now.
So just flash the ROM and enjoy!
(I promise I'll keep a better changelog next time.. was a slacker this week.)
Oh yeah! I changed a few things around in the system to try and reduce
persistance of crashes.
And I think I fixed roaming.
January 15
a2dp is now working fully, as per a few testers + my own observations.
optimization done to system core, more butter.
update device specific files, should yield a slight boost in signal strength
January 11
Changing in-call volume now works.
Took a shot at fixing a2dp.
minor tweaks to the system to try and increase the butter effect.
added 3-dot menu overflow toggle under ROMControl/General UI
few other things i don't recall atm.
January 9, v2
Camera fixed.
Display flicker fixed. (CM Gerrit)
^ this commit is made in the kernel.
If you flash anything other than this kernel, or KToonsez' 1/10
you will have to fix flicker in the build.prop.
January 9
[b]Cherry picks:[/b]
SystemUI: tint alternate icons (small menu, alt back, arrow keys)
SystemUI: more compatibility with themes
QuickSettings: fix vibrate and silence toggle not updating
Framework: NavBarColor (1/2)
RomControl: NavBarColor (2/2)
Don't wake the screen for media playback KeyEvents
Phone: Port CM Advanced Phone Settings
Makes network mode toggle work. Port from CM9.
[b]Stuff from me:[/b]
Cleaned up some of the device stuff in msm8960-common and d2-common
optimized some of the code for 4.7 toolchains (not yet used, but preparing for future.)
optimizing for linaro in the beginning stages
took a shot at fixing the camera.
took yet another shot at fixing screen flicker.
January 7
MMS Themeabilty (aokp)
Noise Suppression on phone calls (aokp)
More toggle preferences (aokp)
Setting to answer phone call with hardware home button (aokp)
Change device hostname (aokp)
Select UI Mode --kinda functional (aokp, small edits here and there by me)
optimizations, too many small lines in too many files to list (mostly aokp, few from me for msm8960 stuff
fixed display flickering for good without a build.prop edit (me)
GAPPS:
http://goo.im/gapps
(grab the latest 4.2 ones)
This now uses GideonX's BMS Kernel for all your tweaking desire. Voltages, frequencies, etc are user configurable in PerformanceControl. Enjoy!
If I have forgotten any thanks or credits please let me know, I'll add them in. Not very good at this whole thread creating bit.
KERNEL SOURCE:
Is now on GideonX's BitBucket at: http://bitbucket.org/gideonx/BMS_JB
one more for good measure, issue posting and fixes, random infos, etc.
Bugs!
Updated: Jan. 26, 1355
Holding hardware "back" key to kill app doesn't work, nor does toggle for it.
This was removed in aokp 4.2, looking into forward porting. Use soft keys for now.
Finally fixed! Eat your heart out, teh roxxorz!
"Torch Off" sticking permanently:
Change the order of the Torch toggle under ROMControl, it will display properly after that.
"Call Volume can't be changed during call":
Looking into this, no workaround yet.
fixed
"Fast Charge toggle not displaying at all":
Also looking into this, no workaround yet.
"Disable LED While Charging":
This is an AOKP feature not yet implemented in the JB-4.2 branch, I'll be keeping my eye on the Gerrit for it, but also will be looking at how to implement it before hand. Stay tuned.
"Voice Dialer stays stuck at start screen"
No fix or workaround yet, looking into it.
Workaround found. Use google now instead of voice dialer. Looking for a real fix still.
Bluetooth A2DP Crackles and cuts out:
Already working on that, will have more info either tomorrow or the day after.
fixed.
WiFi Tethering doesn't work!
Yeah, I know, it's lame. I think it still works with no security. Looking into it; promise.
These are the bugs that have been found so far, if you find anymore, please report!
Running great! Can't decide whether to keep this or go to slim bean
Gonna try this! 3G work? Any bugs we should know?
Sent from my SPH-L710 using xda app-developers app
Think I'll give this a spin.
S3 on the Now Network
Whiplashh said:
Gonna try this! 3G work? Any bugs we should know?
Sent from my SPH-L710 using xda app-developers app
Click to expand...
Click to collapse
3G does indeed work, takes a few seconds to turn on after a boot but it works. just gotta give it time. The only bugs i can think of is 4G/LTE. I don't live in an area with it, so I can't test it. Other than that, I haven't encountered any bugs, but if you do, please tell me!
How about a2dp Bluetooth?
$MyName said:
3G does indeed work, takes a few seconds to turn on after a boot but it works. just gotta give it time. The only bugs i can think of is 4G/LTE. I don't live in an area with it, so I can't test it. Other than that, I haven't encountered any bugs, but if you do, please tell me!
Click to expand...
Click to collapse
So this is what you would call a stable 4.2? Yes!!!
Sent from my SPH-L710 using xda app-developers app
paulg1981 said:
How about a2dp Bluetooth?
Click to expand...
Click to collapse
I haven't been able to test that as i'm on my linux machine and don't have a pair of headphones that use BT, but if you could test that out for me I'd appreciate it! I know BT works, just don't know how well.
Whiplashh said:
So this is what you would call a stable 4.2? Yes!!!
Sent from my SPH-L710 using xda app-developers app
Click to expand...
Click to collapse
I wouldn't call it stable until its gone under more rigorous testing. this is more like a beta build just to see what's up.
I'll report back in a bit on LTE. Flashing now!
Sent from my SPH-L710 using xda premium
$MyName said:
I wouldn't call it stable until its gone under more rigorous testing. this is more like a beta build just to see what's up.
Click to expand...
Click to collapse
Okay
I will test it for you tomorrow. Thank you
Sent from my SPH-L710 using xda app-developers app
Might give this a run tonight. Thanks for the rom OP
Sent from my SPH-L710 using xda app-developers app
Thanks been waiting for this is there really any difference between aokp n cm in the beta stages
And are you going to be building it frequently? Aka nightly
Sorry for my ignorance but will this have the same bugs as CM or is that the benefit of building from source?
How's the battery life guys? Muahahahah jk
Sent from my SPH-L710 using xda premium
Dreamlogix said:
Thanks been waiting for this is there really any difference between aokp n cm in the beta stages
And are you going to be building it frequently? Aka nightly
Click to expand...
Click to collapse
I'll be building it every other night or so, with the exception of tonight. just found some juicy new features that I want to try.
As for differences, well, really this is going to be my pet project. It's turning into AOKP with cherry picks from different places and a bit of class. AOKP and CM aren't -vastly- different, but AOKP is more customizable in my opinion, plus I just love how bloody smooth it is. I'll probably be doing a version with my picks and mods and a standard aokp version without any of my nicities, as they may be unstable.
paulg1981 said:
Sorry for my ignorance but will this have the same bugs as CM or is that the benefit of building from source?
Click to expand...
Click to collapse
depends really. cm and aokp aren't vastly different, but i'm using the CM kernel by default so it might have those bugs in it. the big thing here is the issues can be fixed easier with source, that's why i built this, as the AOKP port currently could inherit other devices bugs and its just a headache.
Wow, great job on this, thanks for sharing it!! I'm getting the phantom VM notification but aside from that I've had no problems at all thus far. Very nice!
Sent from my SPH-L710 using Tapatalk 2
Just flashed and great rim for a first release. Very buttery with ktoons kernel! Found a few bugs....
1. No tile for fast charge appears when selected in toggles
2. No option to turn off battery light when charging
3. Voice dialer stays stuck in starting...
4. Earpiece volume can't be adjusted in call
Bluetooth a2dp is working for me
Thanks for all your hard work
paulg1981 said:
Just flashed and great rim for a first release. Very buttery with ktoons kernel! Found a few bugs....
1. No tile for fast charge appears when selected in toggles
2. No option to turn off battery light when charging
3. Voice dialer stays stuck in starting...
4. Earpiece volume can't be adjusted in call
Bluetooth a2dp is working for me
Thanks for all your hard work
Click to expand...
Click to collapse
1. I'll look into that.
2. AOKP feature, not yet upstream implemented. i'll keep my eye on the gerrit for it.
3. Logcat me.
4. See 3.
[#Intro]
Oh, and now there's these Lollipops I'm handing out. They are free as always, and they are very very delicious.
[#Why]
[#Info]
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 mobile data as much as you; you get the idea.
NOTE: FML is built and tested on the Verizon Galaxy Nexus variant, also known as toro. The GSM Galaxy Nexus variant (the one pertaining to the forum section you're currently in), also known as maguro, is extremely similar in hardware to the Verizon Galaxy Nexus, however I'm not able to test these builds personally. There aren't any code changes between builds for toro and maguro so that I know there shouldn't be any huge issues, but things specific to maguro I'll need feedback on to make sure they're working OK.
[#HowTo]
Latest BuildKitKat/ROM Stable: omni-4.4.4-20140705-maguro-FML.zip (159.07 MB)
KitKat/TWRP Stable: fml-twrp-2.7.1.0-20140705-maguro.img (8.58 MB)
KitKat/ROM Beta: omni-4.4.4-20141015-maguro-FML.zip (160.13 MB)
KitKat/ROM Beta Hotfix: boot.img (4.83MB)
Hotfix Info: The latest beta had a bug on maguro causing the radio to be a jerk and not work. Flashing this boot.img will resolve that issue. If you'd rather not flash it with fastboot like is normally done for .img files, you can use the Flashify app for it, or you can open up the ROM zip and replace the boot.img in there with the hotfix.
Lollipop/ROM Beta: FML-AOSP-5.0-20150108-maguro.zip (194.45 MB)
LOLLIPOP INFO:
USE THESE GAPPS: FML-GApps-5.0.x-20150101-tuna.zip (167.81 MB)
They are based on PA's GApps, huge thank you to them!
Known Issues:
- Camera can be a little touchy, but it generally works.
- Long SMS messages fail to send, fix is on-the-way though.
Lollipop Changelogs can be found in the post below!
(KitKat) BETA INFO:
Beta builds are using updated GPU drivers (and an updated kernel to go with them) courtesy of @Ziyan, as well as being up to date with the latest stuff from OmniROM. NOTE: YOU CANNOT FLASH A DIFFERENT KERNEL WITH THESE BUILDS.
Currently broken with the new GPU drivers:
- Hardware Video Decoding FIXED 2014/10/06
- Hardware Video Encoding(?) FIXED 2014/10/08
- Camera (PARTIALLY) FIXED 2014/10/08
- The stock camera app (as well as Google Camera) has this weird quirk of crashing when pressing the shutter button to take a picture, however many different camera apps on the Play Store (in particular Camera ZOOM FX) work flawlessly. Video recording is generally OK, however I've been getting some reports of the audio and video being a little out of sync, so your mileage may vary...
See the Changelog post below for..... well..... changelogs.
[#GApps]
Known Issues- The screenrecord command does not work directly, however it does work via the Power menu.
- There can be a slight (noticeable, but not huge) delay when pressing the Recents or Home button.
[#Thanks]
[#Donations]
XDA:DevDB Information
FML: Fork My Life, ROM for the Samsung Galaxy Nexus
Contributors
MWisBest
Source Code: https://github.com/MWisBest/
ROM OS Version: 5.0.x Lollipop
ROM Kernel: Linux 3.0.x
Based On: AOSP
Version Information
Status: Beta
Stable Release Date: 2014-07-05
Beta Release Date: 2015-01-08
Created 2014-05-27
Last Updated 2015-01-08
Changelog, News, Etc.
Lollipop Beta Changelogs:
2015/01/08
- Updated the camera HAL.
This is going to be a little... fragile, at first, but in the long run it's needed. Stock camera app saves pictures now at least.
You may also notice that there's a 5.1MP resolution now (clear your camera app's data if you don't see it), despite our camera supposedly being 5.0MP all these years. Turns out the sensor's native resolution is indeed a whopping 16 pixels taller and 16 pixels wider than we've been using.
2015/01/04
- Added back some of the classic FML optimizations and more.
Built with -fstrict-aliasing flag, C++11, and the Linaro GCC 4.9 toolchain.
- Updated to AOSP "android-5.0.2_r1" tag.
As usual, the only real change was them bumping the version number.
- Improved flashing.
The speed of flashing the ROM zip is now much faster.
- Superuser is now built-in.
There's no need to flash SuperSU. You can find Superuser in the Settings app. You may have to enable the "Development Settings" menu to see it.
Some apps are a little sketchy with this Superuser though, most notably Titanium Backup. If you have issues, try flashing SuperSU.
- Video playback should be fixed.
YouTube in particular seems OK. If you have some weird format you're playing back locally I cannot make any guarantees though.
- The camera situation has improved and also regressed.
The stock camera is kinda back to the point of where it was with the KitKat Beta builds:
---- Preview works. Saving photos does not work. Video recording kinda works.
--- However:
---- The camera calibration is a little messed up. Long story, but it'll be fixed soon. So your white balance may look kinda funky, among other things.
- Audio quality is improved, with support for 192kHz FLAC as well.
This is possible thanks to a new audio resampler, which doesn't impose the same sample rate restrictions of the stock Android ones. It also has far better quality than the stock Android resamplers.
- WiiMotes can now be paired via Bluetooth.
I used to be a bit of a Wii hacking enthusiast... I think I still need to add some more stuff to make it useable as a gamepad or something, but yeah.
- Fixed location services issues.
- (toro) Fixed switching between 4G/LTE and 3G/CDMA network settings.
- Kernel changes:
Reclaimed 38MB of RAM from the carveout stuff.
Removed HDMI's framebuffer, saving an additional ~16MB of RAM. With Lollipop, MHL/HDMI out isn't working with our old HWComposer, so might as well save some RAM in the mean time.
Added overclocking support, as well as adjusted the stock frequencies a little.
Added the GPU kernel driver back into the kernel, rather than building it as a separate module.
Switched to LZO compression for the kernel. It results in a slightly larger size to the kernel, but it boots faster.
Added the "purple tint fix".
Added compiler flag to tune code for Cortex-A9 CPU.
Built with Linaro GCC 4.9 toolchain.
(v3): Fixed VYL00M eMMC bootlooping.
Older Builds:
2014/11/16
- Fixed the RIL.
There were a few things that went into this, and I can't really take much credit for it other than being persistent in trying to fix it.
1. rild needed a little fix-up to somewhat return it to pre-Lollipop form. Basically Google is forcing Qualcomm's junk upon the world. @dhiru1602 pointed me in the direction of some commits from rmcc to hardware/ril that fixed this part of the problem.
2. The kernel needed a commit to support some new junk related to networking in Lollipop. @Ziyan linked me to the change in question.
- Updated to AOSP "android-5.0.0_r6" tag.
Really the only change is that the build number is bumped to LRX21T.
- Switched out a couple small proprietary binaries with a reverse-engineered open-source version.
Thanks to @stargo who has really been killin' it for the Motorola OMAP devices recently, we now have a reverse-engineered pvrsrvinit binary (the executable that fires up the GPU drivers on boot-up). This is especially important because the proprietary pvrsrvinit wasn't compiled as PIE (position-independent executable). With Lollipop, they're forcing everything to be PIE, which is good because PIE is better from a security stand-point. Previously I had been adding a workaround to enable support for non-PIE, which I now don't need.
- Built the ROM with "WITH_DEXPREOPT" set to true.
This basically just adds the ".odex" files to /system. With ART this is important because it cuts down on those lengthy boot-up times because instead of compiling the apps' code on the device, it now compiles it on my computer when I build the ROM instead.
- Changed the "Android is upgrading..." screen to prevent burn-in.
Rather than use Lollipop's eye-hurting bright white theme on this screen, I've switched it back to the classic, darker theme.
2014/11/09
- Switched back to the old OTA package format.
With Lollipop they're now, by default, flashing something similar to a system.img. I switched back to the old format. THIS IS CAUSING VERY LENGTHY FLASH TIMES NOW HOWEVER, I HOPE TO FIX THESE SOON.
- Changed the kernel to build with GCC 4.7.
With Lollipop, Google switched to GCC 4.8. GCC 4.8 has never been kind to the Galaxy Nexus kernel, I'm surprised it was booting at all in the first place... or not, for some people. I'm fairly confident this should fix the VYL00M eMMC issue.
- Added "Ambient Display".
Apparently I need to add a "pick-up" or "significant motion" sensor for it though, so it displays something when the phone is picked up.
- Fixed chromium crashing.
This fixes Browser crashing upon open, among other things. This fix has been in chromium itself for nearly 4 months now, I don't know what the heck Google is doing to AOSP to make it so FUBAR lately...
- Fixed lag in Recents menu.
Now it's smoother than KitKat's, in my opinion.
- Added back F2FS support.
F2FS is now supported again, HOWEVER, it is NOT supported on the /system partition. It really didn't do any good for /system anyway.
- Updated various icons.
The Dialer icon in particular was bothering me. Other things that aren't visible in the launcher, e.g. SettingsProvider, have been fixed as well.
- Fixed FLAC playback, among other media decoding issues.
Just needed a sync-up in the device tree with one thing that I think Google DID do a nice job of with Lollipop actually.
KitKat Beta Changelogs:
2014/10/15
- Cleaned up the kernel.
Ziyan went over all his work not long ago and cleaned up the commit history and whatnot. He's letting me do the task of merging in the GPU driver stuff, so I'm currently just getting the kernel to a "clean slate" of sorts for other kernel devs to fork and build off of. Basically this should hopefully be the new "stock" or "Google" kernel. As a result, there's some bells and whistles missing from this build. It does however include some new audio updates that weren't in the previous kernel, which leads me to this...
- Changed audio sampling rate to 48kHz.
Previously the sampling rate has been 44.1kHz. The Galaxy Nexus supports 48kHz though! Here's what mainly sparked this change: since KitKat, the UI audio effects (e.x. touch sounds) have been switching over to 48kHz. With the Galaxy Nexus still using 44.1kHz, UI sound playback became kinda sluggish, and this was a big contributor to it. The UI sounds use the "fast track" audio path (where it tries to do as little processing as it can to the audio in order to play it with a minimum amount of latency), however a requirement of using this is that no resampling (e.g. converting 48kHz to 44.1kHz, like it has been doing currently with KitKat) can be required on the audio being played. Therefore the UI sounds were taking the "deep buffer" audio path, which has a delay to it. In switching to 48kHz, the "fast track" path is actually even faster now than it has ever been previously, and the Galaxy Nexus was already TOP OF THE LINE when it comes to audio latency believe it or not!
Another thing about this is that there is now support for playback of 96kHz audio files.
- Some updates to the camera HAL.
This hasn't fixed the situation of stock and stock-based camera apps crashing when taking a picture, but it's a start on it though.
NOTICE: Poweramp (and probably most other media players that use their own native code for audio playback rather than straight-up using the built-in Android APIs) is being pissy about the sampling rate change. If you experience issues with music playing, especially things like popping or crackling, please try Play Music or Apollo and see if your issue is still present. I know the UIs for Play Music and Apollo are pretty awful, but I can't write my own media player because I'm dealing with this camera stuff!
KitKat Stable Changelogs:
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. :good:
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: Maguro)
ROM: Initial maguro build.
After the great number of improvements I made in the most recent build I did for toro, I figured it was perfect timing to get maguro up and running.
If you'd like to have a look at the toro stuff, it's here: http://forum.xda-developers.com/devdb/project/?id=1098
Let me know if there's any issues!
To-Do.Slim down the build by putting less used stock applications into a separate flashable .zip, such as Browser.
Experiments I'm Looking IntoCreating Black Holes with my phone's ridiculously awesome speed.
Developer InfoThis 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:
Code:
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...
Code:
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:
DSPManager
frameworks/av
bionic
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:
frameworks/base
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.
Flags.
Aaand here we go on compiler flags. For this I'll be referencing the GCC documentation on "GCC command options", here: https://gcc.gnu.org/onlinedocs/gcc/index.html#toc_Invoking-GCC
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...
https://github.com/MWisBest/android_build/commit/c1b041c32572b6ee1bbb17b1fa8c038c5e9fde1f
https://github.com/MWisBest/android_build/commit/95bb49b613424b70af3e820748724fb92ef35b5e
https://github.com/MWisBest/android_build/commit/d2c13f1c35cfa9c114a69c74cfb1c2631643eebc
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:
https://github.com/MWisBest/android_bionic/commit/3b3f59a173a7cc4ff3a1cec4456a99108ce08092
And then it also has to be disabled in ART, that fix courtesy of @metalspring : https://github.com/MWisBest/android_art/commit/9ed3774fcba75077e098720406d261b79bd9baa9
// To be continued.
Small but Helpful ThingsI 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:
Code:
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:
Code:
make -jX otapackage 1> buildstdout.txt 2> buildstderr.txt
, or the other option is to just lump them all into a single file using:
Code:
make -jX otapackage > buildlog.txt 2>&1
This post is a WIP...
As you may or may not have read in the OP, this ROM was built and tested on the Verizon Galaxy Nexus only for about 9 months. I don't own a GSM Galaxy Nexus, so I'm not able to fully test these GSM builds, however the differences between the two are minimal and everything should work OK.
As the Verizon Galaxy Nexus is pretty much only in the USA, one thing I did to reduce the size of the ROM was to cut back on some of the translations. I've kept what I thought were fairly common languages (including outside the USA). Since I've now expanded to the GSM Galaxy Nexus, which is more international, there's a chance that a language you need might be missing. Please just let me know what you need and I'll be more than happy to include it.
Downloading....perfect timing...i am rom hopping for a while and excited to try this, skimmed last few pages of your toro thread :good:
why not take a look at the recent thumb flag optimisation commits that claimed 6x speeds recently...
You have written that you have built CM 10.2 FML version. Is it compatible with maguro? Where can I find it and flash it over my phone just to see it?
pvkiniyan95 said:
Downloading....perfect timing...i am rom hopping for a while and excited to try this, skimmed last few pages of your toro thread :good:
why not take a look at the recent thumb flag optimisation commits that claimed 6x speeds recently...
Click to expand...
Click to collapse
Yeah I replied to that thread... it's bogus, unsafe, and unprofessional. FML was far beyond that stuff since its inception and it has only gotten better since.
qtoo941 said:
You have written that you have built CM 10.2 FML version. Is it compatible with maguro? Where can I find it and flash it over my phone just to see it?
Click to expand...
Click to collapse
This right here is the first build I've done that's maguro compatible, and there's been lots of improvements since when this ROM was based off of CM so even if it'd work on maguro it's not really worth trying at this point. Sorry!
Wow, amazing, i was waiting for this! OmniMetal is a wonderful ROM but we can't except that metalspring will be doing regulary updates since he has a new phone.
This might be the quickest ROM my maguro has ever seen. I can't even believe how fast Chrome opens.
Downloading!
What do you recommend guys, Dalvik or ART?
I've been always using ART before and then I read replies in toro thread, most likely chooses Dalvik eh?
Thank you
ahmadairfan said:
Downloading!
What do you recommend guys, Dalvik or ART?
I've been always using ART before and then I read replies in toro thread, most likely chooses Dalvik eh?
Thank you
Click to expand...
Click to collapse
Only ART! Feel the smoothness
ahmadairfan said:
Downloading!
What do you recommend guys, Dalvik or ART?
I've been always using ART before and then I read replies in toro thread, most likely chooses Dalvik eh?
Thank you
Click to expand...
Click to collapse
pianistaPL said:
Only ART! Feel the smoothness
Click to expand...
Click to collapse
Dalvik! MWis pimped it the **** out!
MWisBest said:
I'm extremely impressed with ART and I know it's Android's future. They will not be including Dalvik in 4.5 based on what I'm seeing in AOSP's master branch currently. I don't think ART will be the default in 4.4.3, there's a number of changes they'd need for that to happen and at this point in 4.4's lifecycle I think it's too late for a major change such as that, but 4.5 and onwards it will be the go-to thing yes.
I'm also extremely happy with how fast Dalvik is in this last build though... here's my observations on it:
Going from a previous build to the new build (after running Dalvik on both), it feels as if I switched from Dalvik to ART but with a 10x faster bootup due to not going through all the ART compilation, not to mention the space saved over ART too.
After that experience, I think this whole ART thing might've been unnecessary or at least would've been delayed if Android wasn't compiled like it's the stone age.
Funny you mention the dalvik-cache thing, it's actually multi-threaded so it is indeed about a 2x speed improvement, nice observation.
Click to expand...
Click to collapse
Ok, end of speaking, phone charged, let's try this ROM!
Wysłane z mojego Galaxy Nexus przy użyciu Tapatalka
@MWisBest Can i let set DexOpt to /cache if i use Banks Core Gapps and i want change to ART?
---------- Post added at 03:29 PM ---------- Previous post was at 03:10 PM ----------
OK, i guess i can't, after boot with ART i get pernamently SystemUI FC So this is a good reason to try this super fast dalvik
pianistaPL said:
Ok, end of speaking, phone charged, let's try this ROM!
Wysłane z mojego Galaxy Nexus przy użyciu Tapatalka
@MWisBest Can i let set DexOpt to /cache if i use Banks Core Gapps and i want change to ART?
---------- Post added at 03:29 PM ---------- Previous post was at 03:10 PM ----------
OK, i guess i can't, after boot with ART i get pernamently SystemUI FC So this is a good reason to try this super fast dalvik
Click to expand...
Click to collapse
thanks for that...u saved my time
gonna flash this B*tch tonite! the changelog looks impressive. one question though do i need to flash the twrp recovery in the OP as well before flashing the ROM. Thanks!
Very fast on dalvik but phone gets mini freeze when i tap recent apps button and when i tap home button (when i have some app opened)
I haven't recent apps buttom freeze/lag only when i am on home screen.
Wysłane z mojego Galaxy Nexus przy użyciu Tapatalka
Hi MWisBest, could you please add Spanish language support for this ROM? I'm very impressed with your work, and I'd like to have it translated.
Thank you very much in advance!.
Enviado desde mi Nexus 7 mediante Tapatalk
ahmadairfan said:
Downloading!
What do you recommend guys, Dalvik or ART?
I've been always using ART before and then I read replies in toro thread, most likely chooses Dalvik eh?
Thank you
Click to expand...
Click to collapse
pianistaPL said:
Only ART! Feel the smoothness
Click to expand...
Click to collapse
osm0sis said:
Dalvik! MWis pimped it the **** out!
Click to expand...
Click to collapse
^What he said. At the very least give Dalvik a try.
pianistaPL said:
Ok, end of speaking, phone charged, let's try this ROM!
Wysłane z mojego Galaxy Nexus przy użyciu Tapatalka
@MWisBest Can i let set DexOpt to /cache if i use Banks Core Gapps and i want change to ART?
---------- Post added at 03:29 PM ---------- Previous post was at 03:10 PM ----------
OK, i guess i can't, after boot with ART i get pernamently SystemUI FC So this is a good reason to try this super fast dalvik
Click to expand...
Click to collapse
That sounds like the issue you'd run into with a GApps package that's too large, if you want to use a GApps package that large with ART you'll have to disable the DexOpt to /cache thing before switching to ART.
pvkiniyan95 said:
thanks for that...u saved my time
Click to expand...
Click to collapse
See above.
gautam_nexus said:
gonna flash this B*tch tonite! the changelog looks impressive. one question though do i need to flash the twrp recovery in the OP as well before flashing the ROM. Thanks!
Click to expand...
Click to collapse
The recovery build is not required, I just figured I'd start uploading them as 1. It's built automatically, and 2. I use it myself.
pianistaPL said:
Very fast on dalvik but phone gets mini freeze when i tap recent apps button and when i tap home button (when i have some app opened)
I haven't recent apps buttom freeze/lag only when i am on home screen.
Click to expand...
Click to collapse
I'll certainly have a look at that and see what's causing it. The Recents issue might be due to the code regarding if OmniSwitch should be opened instead of the usual Recents, as I'm not getting that lag with OmniSwitch enabled as Recents.
mosca_ said:
Hi MWisBest, could you please add Spanish language support for this ROM? I'm very impressed with your work, and I'd like to have it translated.
Thank you very much in advance!.
Click to expand...
Click to collapse
Crap! I do have Spanish included, but the furthest I had gone with testing that stuff was to simply make sure they were listed in "Settings --> Language & input --> Language", which does have Español listed, however I clicked on it now after your post and there are some things that are missing translations, most notably: Settings!!
The good news is that I recently figured out how to properly log my builds, and sure enough I've found some warnings about translations not being included, so I should be able to track down what's causing this and have it fixed for the next build.
MWisBest said:
^What he said. At the very least give Dalvik a try.
That sounds like the issue you'd run into with a GApps package that's too large, if you want to use a GApps package that large with ART you'll have to disable the DexOpt to /cache thing before switching to ART.
See above.
The recovery build is not required, I just figured I'd start uploading them as 1. It's built automatically, and 2. I use it myself.
I'll certainly have a look at that and see what's causing it. The Recents issue might be due to the code regarding if OmniSwitch should be opened instead of the usual Recents, as I'm not getting that lag with OmniSwitch enabled as Recents.
Crap! I do have Spanish included, but the furthest I had gone with testing that stuff was to simply make sure they were listed in "Settings --> Language & input --> Language", which does have Español listed, however I clicked on it now after your post and there are some things that are missing translations, most notably: Settings!!
The good news is that I recently figured out how to properly log my builds, and sure enough I've found some warnings about translations not being included, so I should be able to track down what's causing this and have it fixed for the next build.
Click to expand...
Click to collapse
Polish language doesn't have translated settings too So i'm waiting for new version, thanks
pianistaPL said:
Polish language doesn't have translated settings too So i'm waiting for new version, thanks
Click to expand...
Click to collapse
Thanks for the heads-up, looks like it's ALL the translations for Settings, dang!
[#Intro]
Oh, and now there's these Lollipops I'm handing out. They are free as always, and they are very very delicious.
[#Why]
[#Info]
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.
[#HowTo]
Latest BuildKitKat/Stable: N/A
KitKat/Beta: omni-4.4.4-20141015-toroplus-FML.zip (162.13 MB)
Lollipop/Beta: FML-AOSP-5.0-20150108-toroplus.zip (195.53 MB)
LOLLIPOP INFO:
USE THESE GAPPS: FML-GApps-5.0.x-20150101-tuna.zip (167.81 MB)
They are based on PA's GApps, huge thank you to them!
Known Issues
- Camera can be a little touchy, but it generally works.
Lollipop Changelogs can be found in the post below!
(KitKat) BETA INFO:
Beta builds are using updated GPU drivers (and an updated kernel to go with them) courtesy of @Ziyan, as well as being up to date with the latest stuff from OmniROM. NOTE: YOU CANNOT FLASH A DIFFERENT KERNEL WITH THESE BUILDS.
Currently broken with the new GPU drivers:
- Hardware Video Decoding FIXED 2014/10/06
- Hardware Video Encoding(?) FIXED 2014/10/08
- Camera (PARTIALLY) FIXED 2014/10/08
- The stock camera app (as well as Google Camera) has this weird quirk of crashing when pressing the shutter button to take a picture, however many different camera apps on the Play Store (in particular Camera ZOOM FX) work flawlessly. Video recording is generally OK, however I've been getting some reports of the audio and video being a little out of sync, so your mileage may vary...
See the Changelog post below for..... well..... changelogs.
[#GApps]
Known Issues- The screenrecord command does not work directly, however it does work via the Power menu.
- There can be a slight (noticeable, but not huge) delay when pressing the Recents or Home button.
[#Thanks]
[#Donations]
XDA:DevDB Information
FML: Fork My Life, ROM for the Samsung Galaxy Nexus
Contributors
MWisBest
Source Code: https://github.com/MWisBest/
ROM OS Version: 5.0.x Lollipop
ROM Kernel: Linux 3.0.x
Based On: AOSP
Version Information
Status: Beta
Beta Release Date: 2015-01-08
Created 2014-10-13
Last Updated 2015-01-08
Changelog, News, Etc.
Lollipop Beta Changelogs:
- Updated the camera HAL.
This is going to be a little... fragile, at first, but in the long run it's needed. Stock camera app saves pictures now at least.
You may also notice that there's a 5.1MP resolution now (clear your camera app's data if you don't see it), despite our camera supposedly being 5.0MP all these years. Turns out the sensor's native resolution is indeed a whopping 16 pixels taller and 16 pixels wider than we've been using.
2015/01/04
- Added back some of the classic FML optimizations and more.
Built with -fstrict-aliasing flag, C++11, and the Linaro GCC 4.9 toolchain.
- Updated to AOSP "android-5.0.2_r1" tag.
As usual, the only real change was them bumping the version number.
- Improved flashing.
The speed of flashing the ROM zip is now much faster.
- Superuser is now built-in.
There's no need to flash SuperSU. You can find Superuser in the Settings app. You may have to enable the "Development Settings" menu to see it.
Some apps are a little sketchy with this Superuser though, most notably Titanium Backup. If you have issues, try flashing SuperSU.
- Video playback should be fixed.
YouTube in particular seems OK. If you have some weird format you're playing back locally I cannot make any guarantees though.
- The camera situation has improved and also regressed.
The stock camera is kinda back to the point of where it was with the KitKat Beta builds:
---- Preview works. Saving photos does not work. Video recording kinda works.
--- However:
---- The camera calibration is a little messed up. Long story, but it'll be fixed soon. So your white balance may look kinda funky, among other things.
- Audio quality is improved, with support for 192kHz FLAC as well.
This is possible thanks to a new audio resampler, which doesn't impose the same sample rate restrictions of the stock Android ones. It also has far better quality than the stock Android resamplers.
- WiiMotes can now be paired via Bluetooth.
I used to be a bit of a Wii hacking enthusiast... I think I still need to add some more stuff to make it useable as a gamepad or something, but yeah.
- Fixed location services issues.
- (toro) Fixed switching between 4G/LTE and 3G/CDMA network settings.
- Kernel changes:
Reclaimed 38MB of RAM from the carveout stuff.
Removed HDMI's framebuffer, saving an additional ~16MB of RAM. With Lollipop, MHL/HDMI out isn't working with our old HWComposer, so might as well save some RAM in the mean time.
Added overclocking support, as well as adjusted the stock frequencies a little.
Added the GPU kernel driver back into the kernel, rather than building it as a separate module.
Switched to LZO compression for the kernel. It results in a slightly larger size to the kernel, but it boots faster.
Added the "purple tint fix".
Added compiler flag to tune code for Cortex-A9 CPU.
Built with Linaro GCC 4.9 toolchain.
Older Builds:
2014/11/16
- Fixed the RIL.
(I think, still unsure of toroplus's status.)
There were a few things that went into this, and I can't really take much credit for it other than being persistent in trying to fix it.
1. rild needed a little fix-up to somewhat return it to pre-Lollipop form. Basically Google is forcing Qualcomm's junk upon the world. @dhiru1602 pointed me in the direction of some commits from rmcc to hardware/ril that fixed this part of the problem.
2. The kernel needed a commit to support some new junk related to networking in Lollipop. @Ziyan linked me to the change in question.
- Updated to AOSP "android-5.0.0_r6" tag.
Really the only change is that the build number is bumped to LRX21T.
- Switched out a couple small proprietary binaries with a reverse-engineered open-source version.
Thanks to @stargo who has really been killin' it for the Motorola OMAP devices recently, we now have a reverse-engineered pvrsrvinit binary (the executable that fires up the GPU drivers on boot-up). This is especially important because the proprietary pvrsrvinit wasn't compiled as PIE (position-independent executable). With Lollipop, they're forcing everything to be PIE, which is good because PIE is better from a security stand-point. Previously I had been adding a workaround to enable support for non-PIE, which I now don't need.
2014/11/11
- Switched back to the old OTA package format.
With Lollipop they're now, by default, flashing something similar to a system.img. I switched back to the old format. THIS IS CAUSING VERY LENGTHY FLASH TIMES NOW HOWEVER, I HOPE TO FIX THESE SOON.
- Changed the kernel to build with GCC 4.7.
With Lollipop, Google switched to GCC 4.8. GCC 4.8 has never been kind to the Galaxy Nexus kernel, I'm surprised it was booting at all in the first place.
- Added "Ambient Display".
Apparently I need to add a "pick-up" or "significant motion" sensor for it though, so it displays something when the phone is picked up.
- Fixed chromium crashing.
This fixes Browser crashing upon open, among other things. This fix has been in chromium itself for nearly 4 months now, I don't know what the heck Google is doing to AOSP to make it so FUBAR lately...
- Fixed lag in Recents menu.
Now it's smoother than KitKat's, in my opinion.
- Added back F2FS support.
F2FS is now supported again, HOWEVER, it is NOT supported on the /system partition. It really didn't do any good for /system anyway.
- Updated various icons.
The Dialer icon in particular was bothering me. Other things that aren't visible in the launcher, e.g. SettingsProvider, have been fixed as well.
- Fixed FLAC playback, among other media decoding issues.
Just needed a sync-up in the device tree with one thing that I think Google DID do a nice job of with Lollipop actually.
- Built the ROM with "WITH_DEXPREOPT := true" defined.
This basically has all the system apps compiled before flashing, to cut down on the initial boot-up time which is ridiculously long with ART.
- Changed the "Android is upgrading..." screen to prevent burn-in.
Instead of using the white Lollipop-like look, it now should show up as the old, darker theme.
KitKat Beta Changelogs:
2014/10/15
- Cleaned up the kernel.
Ziyan went over all his work not long ago and cleaned up the commit history and whatnot. He's letting me do the task of merging in the GPU driver stuff, so I'm currently just getting the kernel to a "clean slate" of sorts for other kernel devs to fork and build off of. Basically this should hopefully be the new "stock" or "Google" kernel. As a result, there's some bells and whistles missing from this build. It does however include some new audio updates that weren't in the previous kernel, which leads me to this...
- Changed audio sampling rate to 48kHz.
Previously the sampling rate has been 44.1kHz. The Galaxy Nexus supports 48kHz though! Here's what mainly sparked this change: since KitKat, the UI audio effects (e.x. touch sounds) have been switching over to 48kHz. With the Galaxy Nexus still using 44.1kHz, UI sound playback became kinda sluggish, and this was a big contributor to it. The UI sounds use the "fast track" audio path (where it tries to do as little processing as it can to the audio in order to play it with a minimum amount of latency), however a requirement of using this is that no resampling (e.g. converting 48kHz to 44.1kHz, like it has been doing currently with KitKat) can be required on the audio being played. Therefore the UI sounds were taking the "deep buffer" audio path, which has a delay to it. In switching to 48kHz, the "fast track" path is actually even faster now than it has ever been previously, and the Galaxy Nexus was already TOP OF THE LINE when it comes to audio latency believe it or not!
Another thing about this is that there is now support for playback of 96kHz audio files.
- Some updates to the camera HAL.
This hasn't fixed the situation of stock and stock-based camera apps crashing when taking a picture, but it's a start on it though.
NOTICE: Poweramp (and probably most other media players that use their own native code for audio playback rather than straight-up using the built-in Android APIs) is being pissy about the sampling rate change. If you experience issues with music playing, especially things like popping or crackling, please try Play Music or Apollo and see if your issue is still present. I know the UIs for Play Music and Apollo are pretty awful, but I can't write my own media player because I'm dealing with this camera stuff!
KitKat Stable Changelogs:
N/A
Reserved
Reserved.
Reserved
Reserved.
Finally got FML up for you toroplus guys! Sorry for the long delay.
Awesome...thank you very much MW!!!!!
Wonderful
Currently uploading this to my server and will seed until a stable version is uploaded, then I will replace it. Thank you so much for bringing life into an otherwise fading device. :crying:
Donation sent.
Downloading. Will be my second rom I try;
Beeing the beginner that I am, I have a Maguro so i couldn't install this one.
Sorry.
BennyDS said:
Beeing the beginner that I am, I have a Maguro so i couldn't install this one.
Sorry.
Click to expand...
Click to collapse
Maguro Build is Here.
I've always wondered about this rom as I saw it on the toro thread... will give it a whirl
MWisBest said:
Finally got FML up for you toroplus guys! Sorry for the long delay.
Click to expand...
Click to collapse
Running good so far! I dirty-flashed over the official Omni build I've been running. No problems to report outside of the expected camera weirdness. Play Store camera apps are all over the map in their behavior - CameraZoomFX works perfectly as you reported, Google Camera crashes like the stock camera, Focal doesn't have any display at all. Video recording works but the audio is a bit out of sync, playback is a little choppy on the phone but is smoother on my computer. VideoCam Illusion (which does its own video encoding via software) does not work at all. Video hangouts seem to work fine.
Also, I used the torch quite a bit today, and at one point it quit working and I had to reboot to get it back. It's a bit early to tell, but I'm suspicious that this ROM is affected by the same 'Camera quits working' bug as Ziyan's 'stable' OMAP kernel.
Anyway, thanks again for your amazing work!
I had the same Torch issue as stated above, fixed with a reboot. Im currently running on Ting/ a Sprint MVNO and they are known for having APN issues with 4.4.x roms. When switching to LTE in the settings, the dialer app would crash loop until I switched back to 3g/2g. Flashing an APN zip on their forum fixed the crashing, but havent been able to tell if 4g actually connects as its pretty shotty coverage in my area. But I thought Id share incase someone else is on Ting.
---------- Post added at 05:15 PM ---------- Previous post was at 05:04 PM ----------
Coming from CM 11 I guess I have been lucky as far as not having to do my own work as far as updating the Sprint Profile, and PRL as it was still within the system settings. I have been unable to figure out how to update Profile/PRL on my own as of yet. Any chance one of you may want to share this info? I'd greatly appreciate it.
New build is up.
The ROM is running smoothly with a few hiccups. I have ran into a few problems. Here's some of them that I have found so far:
1. I currently don't have root.
2. The options to "Uninstall/App info" is there but the texts aren't visible.
3. 3G to LTE switching isn't working on the 20141015 nightly build. It was on the 20141014 nightly build.
4. No Up/Down icon on the signal.
bloopblah said:
The ROM is running smoothly with a few hiccups. I have ran into a few problems. Here's some of them that I have found so far:
1. I currently don't have root.
2. The options to "Uninstall/App info" is there but the texts aren't visible.
3. 3G to LTE switching isn't working on the 20141015 nightly build. It was on the 20141014 nightly build.
4. No Up/Down icon on the signal.
Click to expand...
Click to collapse
1. Root works here on FML. THe official build of OmniROM does not include superuser, you need to flash it yourself from recovery.
2. That's been a longstanding bug with Omni on toroplus for some reason.
3. There's no 20141014 build of FML for toroplus - are you using the Omni official build?
4. That's turned off by default - Settings/Bars/Activity Indicators.
Alright, another new build to try out! I will have a couple of ROMs to try on my GNex which is a good thing!
@MWisBest...hopefully you get some donations coming in as well as Musical_Chairs since you guys are putting time and effort into providing new goodies for us.
Hopefully you get some $$$ coming in. It's going to be about a week for me to donate. One thing people don't realize is that donations don't exactly flood in for devs. I released 4 Venum Ice ET4G ROMs and 2 fully inverted black and white Note 2 ROMs including icons, all inverted apps etc. I actually got over 1000 downloads on all 6 ROMs within the first 24 hours and had excellent feedback.... I received a total of 3 donations totaling $12! Lol. What you guys are doing is harder so hopefully some people who are still here show you guys some love for not making this a thread that got closed for inactivity.... Thanks again to both of you.
Sent from my Knox-Blocked P.O.S Tab 3 running same hardware as my GNex using Xparent Gray Tapatalk 2
Wanted to give this rom a shot mainly due to the updated GPU drivers. So far a very smooth experience and pleased with it except for one major bug for my use case: Any video playback either Youtube, MX Player, etc.. after some uptime seems to fail entirely. In the case of YT it'll just sit at a black buffering screen. It'll buffer the data fine going by the progress bar as I've at times had about 1/4 of a 10-15 minute video buffer going by that indication with no playback. If I reboot the phone and give it another shot, it works.
cr08 said:
Wanted to give this rom a shot mainly due to the updated GPU drivers. So far a very smooth experience and pleased with it except for one major bug for my use case: Any video playback either Youtube, MX Player, etc.. after some uptime seems to fail entirely. In the case of YT it'll just sit at a black buffering screen. It'll buffer the data fine going by the progress bar as I've at times had about 1/4 of a 10-15 minute video buffer going by that indication with no playback. If I reboot the phone and give it another shot, it works.
Click to expand...
Click to collapse
That's the same issue as the torch issue mentioned above. It's a hard bug to track down because it takes so long to show up, and AFAIK nobody has found a reliable way to trigger it (other than just wait a day or two for it to show up). If somebody can figure out how to trigger it more quickly, I would like to try a git bisect on Ziyan's stable OMAP kernel (which is affected by the same bug) and see if I can pinpoint what is actually causing it. But without a reliable way to tell if a particular test kernel is good or not, a bisect is more or less useless.
Hi guys. How are you? I'm fantastic right now:
EDIT: Let me fix that a little...
Howdy!
I hereby offer an alternative build of the latest visi0nary's kernel.
The original thread is located here
Please note that the credits remain with BlueFlame4 (the maker of visi0nary's kernel), as this is the same kernel, just differently built.
Some years ago I spent many months trying to optimize UI smoothness and power consumption for a kernel of a different device, in which I succeeded.
From this time I remember some build flags and kernel config settings that improved (scrolling) smoothness and power consumtion for that device at that time.
So, in an attempt to do the same for the P9000, I re-built the latest visionary's kernel with the following differences:
different/improved build flags
minor changes in kernel defconfig
compiled using a self-compiled sabermod toolchain
With these changes in the build process I try to achieve the following things:
improved smoothness/snappiness of the UI (NOT higher benchmarks - I just want the user experience to be as smooth as possible, benchmarks do not really matter)
improved (lower) power consumption
The built kernel feels improved in smoothness to me, but this might be my own biased opinion.
Anyway, I would appreciate, if some of you good people could use this kernel as a daily driver, in order to see after a few days, if there are really any noticable improvements over the original build of visi0nary's kernel. Please report back in this thread, thank you.
Installation: just flash in recovery - delete cache & dalvik cache afterwards (also in recovery, after kernel flash)
Attention: this build is not for cyanogenmod - it's for Stock P8000 ROM or other Stock-based ROMs like Eragon (I'm using it on the latest Eragon myself).
To verify that you are running the alternative build, you will see a "-gueste" (that's me) appendend to the kernel version number (see attached screenshot).
Thanks mate.
I will flash it to See if something is different/improved
Wish you all the best for this project!
Thanks Allways glad to see effort.
Testing will return with feedback.
Thanks for the kernel. I've just flashed it and so far I see that when you go directly to the battery menu from the notification bar, that menu is much snappier. On the stock and on visionary's kernel you had to wait a little bit to see the details of specific apps draining the battery. That's the feedback which I can say now, I'll try to give information about the power consumption in the future. Thanks for developing!
Thanks in advance at all.
For me so far power consumption seems to be very good (while it is not bad on the original build either). I'm anxious to see, how it will compare to the original build after 2 more days.
Hello! I have just fleshed the phone with this kernel. Seems great for now. Will update you for the power consumption in the near future.
P.S Im so happy that someone has taken over this project, and I hope it will keep you developing it!
boka18 said:
Hello! I have just fleshed the phone with this kernel. Seems great for now. Will update you for the power consumption in the near future.
P.S Im so happy that someone has taken over this project, and I hope it will keep you developing it!
Click to expand...
Click to collapse
Actually it is still BlueFlame4's project, as the changes I performed so far do not qualify for this project to be standalone. For now I only intend to make improved builds for visi0nary's kernel, but not my own kernel.
Making an own kernel out of this would include things like porting stuff to the kernel to enable new features - like SIO scheduler or "Snappy compression" for ZRAM, or even an enhanced kernel tweaking tool that allows the user to set additional kernel settings and tweaks in Android GUI.
But this is not the purpose of this thread/project
Stefan Gündhör said:
Actually it is still BlueFlame4's project, as the changes I performed so far do not qualify for this project to be standalone. For now I only intend to make improved builds for visi0nary's kernel, but not my own kernel.
Making an own kernel out of this would include things like porting stuff to the kernel to enable new features - like SIO scheduler or "Snappy compression" for ZRAM, or even an enhanced kernel tweaking tool that allows the user to set additional kernel settings and tweaks in Android GUI.
But this is not the purpose of this thread/project
Click to expand...
Click to collapse
Feel free - that's the spirit of open source! My P8000 is already on eBay so I'll visit this forum less and less. It's good to see people picking up my work though!
Stefan Gündhör said:
Actually it is still BlueFlame4's project, as the changes I performed so far do not qualify for this project to be standalone. For now I only intend to make improved builds for visi0nary's kernel, but not my own kernel.
Making an own kernel out of this would include things like porting stuff to the kernel to enable new features - like SIO scheduler or "Snappy compression" for ZRAM, or even an enhanced kernel tweaking tool that allows the user to set additional kernel settings and tweaks in Android GUI.
But this is not the purpose of this thread/project
Click to expand...
Click to collapse
I understand completely, but I DO hope that u will be able to continue optimising this great kernel!
What new in this kernel?
What the bug fix?
Okalash said:
What new in this kernel?
What the bug fix?
Click to expand...
Click to collapse
Pro Tip: Read the OP :laugh:
For me so far battery life seems to be very good.
After 2 days and 10 hours of uptime I still got 42% battery.
Now this value is not very informative, as it depends heavily on the usage of the phone.
Compared to the original build of the kernel at least power consumption seems to be better on my phone.
During phone uptime I occasionally played games (not very long though), was connected to bluetooth and wifi many hours, browsed through the web regularly and had only few and short phone calls. Over night for some hours I was in flight mode, while last night I wasn't.
Thank you for continuing the project! I flashed the rebuilt kernel because I had a "feeling" that the battery performance of the original Visi0nary kernel was somewhat lower than the stock kernel. (But maybe I am mistaken.)
So far I have no problems with the rebuild kernel. It is too early to comment on battery performance.
Does it make sense to run Skeleton's Seeder app (part of Eragon ROM) in conjunction with this custom kernel?
Moreover, is there any chance to port the P7000 kernel scripts that enable Android device encryption into this P8000 kernel/Eragon ROM? See http://forum.xda-developers.com/elephone-p8000/general/dev-cwm-elephone-p8000-t3200296/page11 The lack of device encryption is my main gripe with the P8000. Apart from that, I love this phone.
-Tiz- said:
Does it make sense to run Skeleton's Seeder app (part of Eragon ROM) in conjunction with this custom kernel?
Click to expand...
Click to collapse
This rebuild of visionary's kernel is feature-equivalent to the original build. So, yes, you can use the seeder app (I use it myself).
Regarding device encryption you need to understand that it has been left out of the ROM most likely on purpose, because this is a China-phone, and the chinese government is quite restrictive on encryption. And as Eragon (same as other stock-based ROMs) is based on the stock ROM, this feature is missing there as well.
This means, depending on the effort, Elephone made, to remove this feature from Android, it might be possible to reactivate it, it's just a matter of (testing) time.
I haven't tried with other ROMs like Cyanogenmod, but in theory it should work there.
As far as I have seen, the to enable encryption for P8000 stock and stock-based ROMs we would need to modify one or more scripts of the P8000 ramdisk (for example the russian guy you linked added in init.environ.rc:
Code:
export LD_PRELOAD libsigchain.so
And there are also a couple of other differences in the other rc scripts. It's not exactly clear (to me), which changes in the end are required for encryption to be enabled. Also we don't know if after these changes, the encryption option will magically appear in the device settings, or if we need to enhance the menu ourselves.
Furthermore, the russian guy mentions, that we might have to modify and rebuild the sepolicy binary file located in the ramdisk, in order to get selinux (security enhanced linux) to permit our changes (but I don't know if we would need that just for the encryption feature, as init.d already works for P8000 as opposed to P7000 - correct me if I'm wrong).
So to sum up, this sounds like a lot of testing, which I personally don't have the time for But maybe someone else does.
Don't take the Android encryption feature too seriously - at least not, if you are trying to hide from government. However, if you are trying to protect your data from normal people, it surely would be nice to have.
Stefan Gündhör said:
Tin order to get selinux (security enhanced linux) to permit our changes (but I don't know if we would need that just for the encryption feature, as init.d already works for P8000 as opposed to P7000 - correct me if I'm wrong). ...
However, if you are trying to protect your data from normal people, it surely would be nice to have.
Click to expand...
Click to collapse
Thanks. It is also my understanding that init.d already works for Eragon ROM. Therefore, I was hoping that it might be relatively easy to enable encryption. On the P7000, it seems that the menus simply appeared once the scripts were implemented. Wooster even talked about the possibility to make a "blind" patch for the the P8000.
Moreover, I agree that Android device encryption might not be 100% bullet-proof. However, it would allow me and others to sufficiently protect private email passwords and work-related data (e.g. if the phone gets lost or stolen). By contrast, the screen lock is no protection at all. In particular, if a custom recovery is installed ...
It appears that I am not the only P8000 owner who has a vital interest in device encryption:
http://bbs.elephone.hk/thread-6924-1-1.html#.Vow51hBukwE
http://bbs.elephone.hk/thread-9012-1-1.html#.Vow51xBukwE
Tonight I will download and test it
I don't care much about encryption, but God, I would pay for someone who could actually SOLVE the sub-15% sudden battery charge. Any chance you can look into/fix it, Stefan? You look like one of our potential hopes, haha
---------- Post added at 02:42 PM ---------- Previous post was at 02:41 PM ----------
BlueFlame4 said:
Feel free - that's the spirit of open source! My P8000 is already on eBay so I'll visit this forum less and less. It's good to see people picking up my work though!
Click to expand...
Click to collapse
Hi, sorry to ask but why exactly? Got a new/better phone? Got tired of the P8000 bugs/camera? In time, which phone did you get?
Best regards
Rizera said:
Hi, sorry to ask but why exactly? Got a new/better phone? Got tired of the P8000 bugs/camera? In time, which phone did you get?
Best regards
Click to expand...
Click to collapse
No problem, haha. Well, I bought this phone because I want to learn how to port CM or ROMs in general onto other devices and how Android works internally. Unfortunately MediaTek SoCs are quite beginner-unfriendly so I'll go for Qualcomm for now. Just got my Elephone Trunk btw Also there's basically zero "from source" development going on the the P8000 and it's not really fun to do all the things completely alone.
Cheers!
1.
Battery performance of the newly built kernel seems to be good. Heavy WLAN browsing still quickly kills the battery. But I could imagine that this is a hardware issue (power inefficient Mediatek WLAN modem?).
2.
"Also there's basically zero "from source" development going on the the P8000 and it's not really fun to do all the things completely alone. " Sad but true.
Announcing kernel "guestekrnl" (based on the latest version of visi0nary's kernel): http://forum.xda-developers.com/elephone-p8000/orig-development/kernel-guestekrnl-v1-6-2-t3287518