[ROM][14-03-2014] AOSP KitKat 4.4.2 Mod for Nexus S - Final Build

Search This thread


Inactive Recognized Contributor
Mar 10, 2013
love this one. switched over from ephendirx and its much smoother on my NexS. Though Ephendrix was nice also.

Does this one have volume wake to unlock? I tried looking in the settings but couldnt find it. This is actually my second ownership of a nexus s and I highly anticipate this volume button dying as well.


Use xposed framework..

Sent from my Nexus S using XDA Premium 4 mobile app


Hi Guys, I've got my old nexus s back. I'm going to flash 4.4.3 rc 1.1 on it.

Then I'm going to build some marmite.


Senior Member
Oct 15, 2009
This is the most responsive and smoothest ROM for Nexus S that I've ever tried !
Anyone feels the same ?

I hope cn.fyodor could keep update this ROM to 4.4.4 and further more future version !

it's beyond slimrom which is also very smooth, so i think the same that is the best rom for nexus.Good Job.
All nexus s users are waiting for a 4.4.4 cn.fyodor update so we hope it will appear eventually.


Senior Member
May 25, 2012
just installed 4.4.2 build 5 + gapps mini 4-4-4

unable to use data

unable to add APN

any suggestion??



Senior Member
Jul 31, 2011
Gainesville, Fl
Google Nexus 4
T-Mobile LG G2
Is this CM or AOSP? I couldn't quite tell from the description since the OP mentions borrowing from both. I'm looking for a pure AOSP KK build (preferably 4.4.4 KTU84P) for NS to use as a base for a NS4G port. If anyone can help, please let me know!!

Top Liked Posts

  • There are no posts matching your filters.
  • 120
    Hi folks,

    There seem already many AOSP builds for NS, but I'm just pleased to share my personal build with you. I took the Google source and CM kernel/vendor as a base and have done lots of optimization work. My changes for NS after forking CM vendor were listed in the changelog of the initial build. Devs can check out commits on my github. It may worth a note that it's AOSP so never request extra features. No doubt I will keep it as stock as possible.

    • clearly go to CM Team and all worked for our NS
    • steven676 for SurfaceFlinger and other patches

    Final Build | MD5: 47af680bd273732d751de65656f62f7e

    I don't hold the Nexus S any more, so if something in the final build does stupid for you, fall back to Build 6. And at last thank you again for your support.


    android-4.4.3-r1.1 build can be found in this reply. Panorama issue has been fixed.

    You can find out all changes on my Github. Remember that AOSP ROM doesn't include Gapps, you have to install/flash it yourself.


    Final Build
    • android-4.4.2_r2
    • merged some fixing patches from CM etc

    Build 6
    • fixed random rebooting issue
    • saved about 3MB memory from the Kernel, thanks to pawitp

    Build 5
    • android-4.4.2_r1
    • added swipe the pull-down panel to switch between Notifications and QuickSettings, thanks to CM/Slim
    • speed up statubar/notification drawer, thanks to kufikugel
    • changed dalvik heap parameters to reduce memory footprint (CodeAurora)
    • used double buffering instead of triple buffering
    • disabled hardware Vsync completely
    • fixed Screen record function, but in landscape only
    • increased the extra free memory to 12MB (you can change it in build.prop at any time.)

    alpha 4
    • increased EGL cache size
    • switched to SW-based Vsync implementation by Google
    • fixed Keyguard layout for some languages
    • added a workaround to suppress the SU binary deprecated warning
    • few patches in Kernel and other minor fixes in SurfaceFlinger

    alpha 3
    • merge in AOSP 4.4_r1.2
    • WebView black square issue was gone. Thanks to klusark for the wonderful porting work.
    • fixed app to sdcard function
    • enable low RAM feature in 4.4
    • root access fixed in Superuser with ART enabled
    • add Emoji support
    Changes from init alpha Build:
    • merge the extra free kbytes patch from 3.4 Kernel
    • enable Swap for zRAM and KSM in Kernel side
    • Kernel 3.0.101
    About those PVR crashes ...

    Does https://android.googlesource.com/pl...+/2aff7025482cc40d2ebd45f81cdb318ac1c6f868^!/ (in AOSP master, but not in 4.4 or in CM EDIT: merged) help? I've been running it for several days now on tuna without seeing crashes, graphical glitches or loud PVR debug dumps in dmesg.

    Given that those PVR debug dumps appear to correspond to these messages in the Android log:

    W/GraphicBufferMapper(  748): registerBuffer(0x5dc22c88) failed -22 (Invalid argument)
    E/GraphicBuffer(  748): unflatten: registerBuffer failed: Invalid argument (-22)

    that suggests the following chain of events leading to the crash:

    • Registering a gralloc buffer fails (for unknown reasons, probably something to do with things that happen in the proprietary blobs).
    • GraphicBuffer::unflatten() returns an error, but (without the patch above) does not clean up after itself.
    • Something else comes along and attempts to use the GraphicBuffer object, which now contains a pointer to god-knows-what. This could cause memory corruption, leading to graphical glitches and (eventually, unpredictably) crashes.

    With the linked patch applied, I still see those registerBuffer() failures in logcat output, but never screen corruption or the stack dumps in dmesg.

    EDIT: One other patch of interest: https://github.com/CyanogenMod/andr...mmit/0f93dc6e231e915c82ede24bace1091a1c62569e appears to be a workaround for the garbage you see in the screenshot animation. (It probably shouldn't be called a fix, given that all it does is copy the contents of one bitmap to another.) Ignore me, that seems to be an OMAP4-specific problem.
    quick alpha 4.4 build

    Hi all,

    After check-picking several patches from @steven676, here is a quick alpha KitKat build for you. Don't hope too much. Browser rendering is broken. And for now I don't have the time to fix bugs. The only thing I can confirm is that it's just running pretty fast. lol

    Download KitKat | Mirror. MD5: d1e025e977c24a9249087bf928230999

    What works:
    Call, 3G data, SMS, Wifi, Bluetooth(?), light/gravity sensors, Camera, sdcard, NFC, CRT off, Superuser etc

    Serious bugs:
    • WebView is mostly broken. This means you will get black squared screen in all apps which use WebView as their built-in net viewer.
    • Most of gapps not working properly as others report.
    • Lags here and there, but in general it's faster than 4.3 AOSP for me. If you run into severe lags, did you do factory reset before flashing?
    Thanks for all reports and feedback.

    Also please note:
    • Take It As Your Own Risk.
    • latest CWM is required. I'm using version.
    • frameworks and dalvik are built from stock AOSP.
    • No Launcher3, no Live wallpapers. L3 seems boring without gapps.
    • Don't enable ART run-time or you will get lots of FC since most of apps are not ready with it.
    • Kernel was already updated to 3.0.101.

    Excellent news on this front: cdesai and klusark found a patch in the Chromium trunk which fixes the WebView rendering bug on PVR devices and backported it to the Chromium snapshot that's part of 4.4. (The fact that it's part of the mainline Chromium code also means that we shouldn't face this problem again when upgrading to future Android releases.)
    Yeah, klusark has notified me about this patch. Wonderful work! Thank you, guys.

    good news !!! so @cn.fyodor we can now have a rom with this and app to usb storage????
    Definitely, and we'll also get 4.4_r1.2 updates with minor fixes. :p
    Yesterday I was looking around in SurfaceFlinger.cpp. I found the native screen capture also calls eglCreateImageKHR() function with the same target but difference buffer source and NULL EGL attrs. This capture implementation was also firstly introduced in 4.4 probably for performance. As you know, screen capture never fails in our devices. The buffer used in screen capture was dequeued from the current window. I tried the KHR function with NULL attrs in chromium, but still no luck. So I think the possible bad parameter error could be only caused by the EGL buffer management.

    That's an interesting observation, and I suspect you're right that it has something to do with the buffer. That said, I just can't find anything in the code or in the debugger that gives any clue as to what that might be -- perhaps it has to do with state that's internal to the PVR driver?

    When the WebView requests buffer of EGL_CLIENT_BUFFER type, GLImageEGL::Initialize will be called. It's done by the case-switch code in gl_image_android.cc. But it seems difficult to trace the buffer usage in chromium. Did you try it? xD

    This is a bit of a disorganized infodump from my various bouts with gdb and webviewchromium, but here goes:

    • The EGL_NATIVE_BUFFER_ANDROID type to eglCreateImageKHR() is defined in the EGL_ANDROID_image_native_buffer extension (supported by our driver -- it's mandatory for Android EGL implementations). It tells us that the EGLClientBuffer (a typedef for (void *) ... god, I hate APIs that do this) passed in to the call must be a pointer to an ANativeWindowBuffer (system/core/include/system/window.h). That said, I've never seen webviewchromium pass anything other than a pointer to a GraphicBuffer (frameworks/native/include/ui/GraphicBuffer.h and frameworks/native/libs/ui/GraphicBuffer.cpp).
    • That GraphicBuffer is obtained via a call to CreateGpuMemoryBuffer() in an instance of ImageFactory (external/chromium_org/gpu/command_buffer/client/image_factory.h). But here's where things get strange: the only instance of ImageFactory that turns up in the entire Chromium codebase in searches via AndroidXref or Ohloh is GLInProcessContextImpl (external/chromium_org/gpu/command_buffer/client/gl_in_process_context.cc). That implementation delegates to an instance of GpuMemoryBufferFactory, which has only one implementation -- the Android WebView-specific GpuMemoryBufferFactoryImpl class (external/chromium_org/android_webview/browser/gpu_memory_buffer_factory_impl.{h,cpp}). That implementation obtains its GpuMemoryBuffer from the libwebviewchromium_plat_support library (frameworks/webview/chromium/plat_support/gpu_memory_buffer_impl.{h,cpp}), which gives it something which is basically a thin wrapper over libui's GraphicBuffer. In summary, by all appearances, this rendering path is specific to the Android WebView, which explains why Chrome for Android doesn't have this problem.
    • A quick examination of GpuMemoryBufferImpl in the plat_support library reveals the reason for the "mismatching lock usage flags" message on OMAP4: the buffer is always created with USAGE_HW_TEXTURE|USAGE_SW_READ_OFTEN|USAGE_SW_WRITE_OFTEN, but locked with one or both of USAGE_SW_READ_OFTEN or USAGE_SW_WRITE_OFTEN. (That message comes from the OMAP4-specific gralloc module, which explains why we don't see it on S5PC110.) But adjusting GpuMemoryBufferImpl so that the flags always match doesn't solve the problem. Other than that, I can't find anything remarkable in the way Chromium uses the GpuMemoryBuffer, though perhaps I haven't been looking hard enough in the right places -- maybe you (or someone else) will have more luck chasing this down.
    • We can't switch to the regular Chrome rendering path, because Chrome runs its GPU rendering in a separate process. I don't believe we can create new processes when initializing an Android WebView -- it's unsafe to fork() a multithreaded process unless the child process immediately exec()s another program, and the app using the WebView could have created any number of threads before initializing us. (That explains the separate "in-process" rendering pipeline for the Android WebView, where the GPU renderer runs in a thread of the main process.)
    • That said, we can try to avoid the use of EGLImages in the tile manager (external/chromium_org/cc/resources/tile_manager.cc). It appears that, when an ImageFactory instance isn't available, the tile manager will render into pixel buffers instead of EGLImages (external/chromium_org/cc/resources/{pixel_buffer,image}_raster_worker_pool.cc; the selection between the two is done when the tile manager initializes). Since ImageFactory appears to only be available through the Android WebView, I assume that Chrome uses the pixbuf renderer. (I haven't chased that down completely, so don't take that as gospel.)
    • It's possible to disable the use of EGLImages in the Android WebView with this brief patch (against external/chromium_org):
      --- a/android_webview/lib/main/aw_main_delegate.cc
      +++ b/android_webview/lib/main/aw_main_delegate.cc
      @@ -56,8 +56,10 @@ bool AwMainDelegate::BasicStartupComplete(int* exit_code) {
         CommandLine* cl = CommandLine::ForCurrentProcess();
      +#if 0
         if (!cl->HasSwitch("disable-map-image"))
         // WebView uses the Android system's scrollbars and overscroll glow.
      That eliminates the black tiles, but the rendering still doesn't work correctly -- you now sometimes get tiles that are blank except for the background color of the webpage in question (no text or images). I guess no one's tested the pixbuf renderer in the WebView-specific in-process rendering path in a while? That said, it may be worth pursuing this further -- it seems likely that this is a bug in the Android WebView or Chromium, which we can (in principle) find and fix. By contrast, the EGLImage problem seems likely to be a GPU driver bug, which we're struggling to characterize in the first place, and which we can probably at best try to work around by avoiding the broken functionality.

    Must ... sleep ... now ...... zzzzzzzzzzzzzzzz.