[ROM][14-03-2014] AOSP KitKat 4.4.2 Mod for Nexus S - Final Build
- Thread starter cn.fyodor
- Start date
Is it compatible with SlimGApps 4.4.4, if it's TRDS-compatible[The.Real.Dark.Slim]?
Last edited:
After trying about 10 roms, I can safely say teveryone that this is the best rom for crespo. Nothing beats this(untill Lollipop comes out).
Lollipop will never come out for Crespo because our device configuration is too low to handle 5.0...
Better move on to other Device..
Galaxy S.
Almost same as our Nexus S, yet it gets plenty of 5.1 roms.
Can someone tell me that is it safe to flash Galaxy S's roms?
Almost same as our Nexus S, yet it gets plenty of 5.1 roms.
Can someone tell me that is it safe to flash Galaxy S's roms?
The latest one that @cn.fyodor posted is here http://xdaforums.com/showpost.php?p=53264180&postcount=728 but this link and all other links at uploadingit.com have been pulled ... weird.
The file is aosp-4.4.3-20140609-crespo.zip and when you google it you can find a few chinese sites where you can download it, but it is not the same file. I did an MD5 check and it failed and I then noticed there was a small difference in filesize.
Anyway here is the file: http://www.filedropper.com/aosp-443-20140609-crespo
the MD5 Hash is: 78043F66677A917948C99ECDEDD73570.
Z
Last edited:
I personally don't use it as I want to keep my phone lightweight
To get the file go to androidfilehost.com and search for gapps-kk-20140105-signed.zip
Sorry for not providing a link, for some reason XDA won't let me post external links until I make 10 posts, apparently to stop SPAM, even though my previous post has an external link. Maybe this is a new anti-spam counter measure they have just implemented.
Z
Follow my signature.. I have a link to all the files I had from my NS, there's a copy there..
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
120Hi 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:
- panorama preview. Check out CataHd's reply for the fix.
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:
22About those PVR crashes ...
Does https://android.googlesource.com/pl...+/2aff7025482cc40d2ebd45f81cdb318ac1c6f868^!/ (in AOSP master, but not in 4.4or in CMEDIT: 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.20quick 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?
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,18
Yeah, klusark has notified me about this patch. Wonderful work! Thank you, guys.
Definitely, and we'll also get 4.4_r1.2 updates with minor fixes.16
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?
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):
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.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);
Must ... sleep ... now ...... zzzzzzzzzzzzzzzz.
