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

Search This thread
By:
Advanced…
cn.fyodor

cn.fyodor

Senior Member
Dec 31, 2009
332
499
Nanjing
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.

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

Download:
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.

Issues:

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.
Cheers,

Changelog:

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
 

Attachments

  • Launcher3.apk
    1.6 MB · Views: 10,064
Last edited:
  • Like
Reactions: Tranzior, happyrik, antifocus and 117 others
ej8989

ej8989

Senior Member
Jul 8, 2012
1,750
587
Manila
It's working fine. Very stock-ish feel. No FCs whatsoever (except for apps that are yet to be updated to fully support 4.3)
 
leap_ahead

leap_ahead

Senior Member
Jul 2, 2009
3,229
619
excellent rom thanks !!!!
only problem with superuser..I must install zip from recovery !!
then all ok !!
 
leap_ahead

leap_ahead

Senior Member
Jul 2, 2009
3,229
619
cn.fyodor said:
Thanks for trying. :p But Superuser was fixed for weeks and works for me.
Click to expand...
Click to collapse

no my friend .. I flash 3 times to make it sure and no work :p

if you go to settings superuser then u will se that u cant change anything in superuser settings..

also check with root checker..

but don't worry !! this is nothing for this super rom !! I try all aosp 4.3 rom and this is the best for me !!
 
Last edited:
cn.fyodor

cn.fyodor

Senior Member
Dec 31, 2009
332
499
Nanjing
leap_ahead said:
no my friend .. I flash 3 times to make it sure and no work :p

if you go to settings superuser then u will se that u cant change anything in superuser settings..

also check with root checker..

but don't worry !! this is nothing for this super rom !! I try all aosp 4.3 rom and this is the best for me !!
Click to expand...
Click to collapse
I tried changing settings in Superuser, every option works like charm. I always chased the changes of Superuser by Koush and the hack in that Superuser zip was included in my ROM. Afaik the tweak is just to run '/system/bin/su --daemon' for the root requirement.

OK, anyone else got superuser issue? xD
 
  • Like
Reactions: dark'em and leap_ahead
ej8989

ej8989

Senior Member
Jul 8, 2012
1,750
587
Manila
leap_ahead said:
no my friend .. I flash 3 times to make it sure and no work :p

if you go to settings superuser then u will se that u cant change anything in superuser settings..

also check with root checker..

but don't worry !! this is nothing for this super rom !! I try all aosp 4.3 rom and this is the best for me !!
Click to expand...
Click to collapse

cn.fyodor said:
I tried changing settings in Superuser, every option works like charm. I always chased the changes of Superuser by Koush and the hack in that Superuser zip was included in my ROM. Afaik the tweak is just to run '/system/bin/su --daemon' for the root requirement.

OK, anyone else got superuser issue? xD
Click to expand...
Click to collapse

Works fine here.
 
leap_ahead

leap_ahead

Senior Member
Jul 2, 2009
3,229
619
cn.fyodor said:
I tried changing settings in Superuser, every option works like charm. I always chased the changes of Superuser by Koush and the hack in that Superuser zip was included in my ROM. Afaik the tweak is just to run '/system/bin/su --daemon' for the root requirement.

OK, anyone else got superuser issue? xD
Click to expand...
Click to collapse

I don't know ..is not work here for that I flash the zip ..

sorry but is ok to flash the zip ? or I must try again without the zip ?

*now I remember that I get notification that su is out date and I forget to click ...
Downloaded and installed the latest superuser.zip and the su binary out of date notification is gone
 
Last edited:
V

velishka

Senior Member
Nov 20, 2010
129
44
Very good job. So happy to see the deveopment for our old phone continues.
Now, I can confirm Superuser doesn't work. Flashing SuperSU from recovery fixed the issue pretty fast.
Other than that the ROM is very solid and smooth. I tested SMS, Location services, Wi-Fi, left phone without a charge for a night. No problems so far. Will test bluetooth streaming later today in my car.
I have the same issue with calendar like any other non google build has, I have two of them, one is AOSP build another is Google's from the play store. That doesn't bother me.

Also, I still want to know what kind of "optimization" was done. Also, can anyone test MTP for me? I turned it on using USB Switcher, but my computer didn't recognize the device.

Great job, I hope the project continues.
 
  • Like
Reactions: xiaoker and leap_ahead
cn.fyodor

cn.fyodor

Senior Member
Dec 31, 2009
332
499
Nanjing
@leap_ahead, velishka:
Let's rule out some exceptions about Superuser issue. Did you do factory reset before flashing? I hope the old Superuser app didn't make noise. Although you guys have fixed it manually, I still hope someone can paste the output of command 'getprop persist.sys.root_access' and check if the /system/xbin/su is running when you can't get root permissions. Thank you.
 
  • Like
Reactions: londho
lagloose

lagloose

Senior Member
Feb 11, 2008
728
2,969
Hey,
just had a closer look at your build and found the interesting property 'ro.sys.fw.bg_apps_limit' in your build.prop which is set to 8. Are you sure this works in your build ? (I only ask because this was seen only in CM until now)...

Greetz
 
  • Like
Reactions: leap_ahead
cn.fyodor

cn.fyodor

Senior Member
Dec 31, 2009
332
499
Nanjing
lagloose said:
Hey,
just had a closer look at your build and found the interesting property 'ro.sys.fw.bg_apps_limit' in your build.prop which is set to 8. Are you sure this works in your build ? (I only ask because this was seen only in CM until now)...

Greetz
Click to expand...
Click to collapse
Yeah, CM merged that commit from Codeaurora afaik. Bet you haven't checked out my github yet. xD
 
  • Like
Reactions: leap_ahead
leap_ahead

leap_ahead

Senior Member
Jul 2, 2009
3,229
619
velishka said:
Very good job. So happy to see the deveopment for our old phone continues.
Now, I can confirm Superuser doesn't work. Flashing SuperSU from recovery fixed the issue pretty fast.
Other than that the ROM is very solid and smooth. I tested SMS, Location services, Wi-Fi, left phone without a charge for a night. No problems so far. Will test bluetooth streaming later today in my car.
I have the same issue with calendar like any other non google build has, I have two of them, one is AOSP build another is Google's from the play store. That doesn't bother me.

Also, I still want to know what kind of "optimization" was done. Also, can anyone test MTP for me? I turned it on using USB Switcher, but my computer didn't recognize the device.

Great job, I hope the project continues.
Click to expand...
Click to collapse
I connect the phone to car radio so it ok !
for root you can flash the superuser from koush too ...
use marmite kernel for mtp ...
I use other gapps so I don't have the problem with two calendar ..only one I get the green one ...

---------- Post added at 05:26 PM ---------- Previous post was at 05:25 PM ----------
cn.fyodor said:
@leap_ahead, velishka:
Let's rule out some exceptions about Superuser issue. Did you do factory reset before flashing? I hope the old Superuser app didn't make noise. Although you guys have fixed it manually, I still hope someone can paste the output of command 'getprop persist.sys.root_access' and check if the /system/xbin/su is running when you can't get root permissions. Thank you.
Click to expand...
Click to collapse

yes I make full wipe and ofcource factory reset ! with twrp recovery !
 
leap_ahead

leap_ahead

Senior Member
Jul 2, 2009
3,229
619
cn.fyodor said:
[*]Superuser fails (Workaround is to run '/system/xbin/su --daemon' via adb shell, then go to Superuser settings -> allow root access. Then it'll be fine even after a reboot. Thanks to leap_ahead for bug report)
[*]Gesture typing not working?


[/LIST][/HIDE]
Click to expand...
Click to collapse

or you can flash via recovery the superuser zip from here :http://download.clockworkmod.com/superuser/superuser.zip

for gesture I use other gapps that gesture is working without any problem
 
  • Like
Reactions: cn.fyodor
lagloose

lagloose

Senior Member
Feb 11, 2008
728
2,969
Used this baby for 3 days now and have to say that it has the best memory management for 'low-memory' devices i've seen until now. Whatever you did cn.fyodor, very good work. !
I've noticed that CM has already reverted the commit for property 'ro.sys.fw.bg_apps_limit'. You should take care that this is not reverted in your sources because IMHO this is one of the essential things which gives us this better memory management. The relevant part can be found in line 105 of https://github.com/Juansheng/androi...s/java/com/android/server/am/ProcessList.java in your github.

Greetz
 
  • Like
Reactions: leap_ahead
cn.fyodor

cn.fyodor

Senior Member
Dec 31, 2009
332
499
Nanjing
lagloose said:
Used this baby for 3 days now and have to say that it has the best memory management for 'low-memory' devices i've seen until now. Whatever you did cn.fyodor, very good work. !
I've noticed that CM has already reverted the commit for property 'ro.sys.fw.bg_apps_limit'. You should take care that this is not reverted in your sources because IMHO this is one of the essential things which gives us this better memory management. The relevant part can be found in line 105 of https://github.com/Juansheng/androi...s/java/com/android/server/am/ProcessList.java in your github.

Greetz
Click to expand...
Click to collapse
Thanks for your suggestion. Actually I once changed MAX_HIDDEN_APPS back the default value in Gingerbread for low memory devices nine months ago. Check this commit. ro.sys.fw.bg_apps_limit was just introduced by Codeaurora recently. And yeah CM have already reverted this prop and added a new prop for high memory (> 1.5GB) devices since more CM supported devices hold more memories nowadays. I'll ignore that commit. :p

Cheers,
 
  • Like
Reactions: V_tunes and leap_ahead
You must log in or register to reply here.

Similar threads

K
[ROM][AOSP] ICS build for Nexus S - v3
Replies
3K
Views
800K
E
ecoe3
KalimochoAz
[ROM] [i9020/23] CyanogenMod 9 v4.0.4 v7.0 + CM Night builds
Replies
7K
Views
2M
M
monddia
B
[KERNEL] marmite v10.6 final
Replies
9K
Views
1M
leap_ahead
leap_ahead
Cybergr
[ROM][IMM76I]CyberGR-MOD|NS.NGN ICS v.14 HYBRID|TWEAKS++|MODS++|Tropical Hurricane!
Replies
4K
Views
777K
hauckk@sfreserves.org
[email protected]
AndroidUser00110001
[ROM][13-04-12][AOSP][4.0.4]Codename Android 2.0.0RC|Fully Open Source+Nightly Builds
Replies
3K
Views
567K
sidnoit22
sidnoit22

Top Liked Posts

24 Hours All time
  • There are no posts matching your filters.
  • 120
    cn.fyodor
    cn.fyodor
    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.

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

    Download:
    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.

    Issues:

    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.
    Cheers,

    Changelog:

    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
    View
    22
    S
    steven676
    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:

    Code: 
    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.
    View
    20
    cn.fyodor
    cn.fyodor
    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 6.0.4.3 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.

    Cheers,
    View
    18
    cn.fyodor
    cn.fyodor
    steven676 said:
    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.)
    Click to expand...
    Click to collapse
    Yeah, klusark has notified me about this patch. Wonderful work! Thank you, guys.

    leap_ahead said:
    good news !!! so @cn.fyodor we can now have a rom with this and app to usb storage????
    Click to expand...
    Click to collapse
    Definitely, and we'll also get 4.4_r1.2 updates with minor fixes. :p
    View
    16
    S
    steven676
    cn.fyodor said:
    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.
    Click to expand...
    Click to collapse

    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?

    cn.fyodor said:
    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
    Click to expand...
    Click to collapse

    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):
      Code: 
      --- 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();
   cl->AppendSwitch(switches::kEnableBeginFrameScheduling);
+#if 0
   if (!cl->HasSwitch("disable-map-image"))
     cl->AppendSwitch(cc::switches::kUseMapImage);
+#endif
 
   // WebView uses the Android system's scrollbars and overscroll glow.
   cl->AppendSwitch(switches::kHideScrollbars);
      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.
    View

New posts