4.4.2 - kot49n
- Thread starter Flypwnz
- Start date
H
Hammer_Of_The_Gods
Guest
Hi,
But if I'm not wrong 4.4.2 is only KOT49H?
https://developers.google.com/android/nexus/images#hammerhead.
Also it's me or the "dev-keys" should be "test-keys" or "release-keys"? But not sure about this, I don't remember on stock...
But if I'm not wrong 4.4.2 is only KOT49H?
https://developers.google.com/android/nexus/images#hammerhead.
Also it's me or the "dev-keys" should be "test-keys" or "release-keys"? But not sure about this, I don't remember on stock...
Last edited:
Hi. Yes I'm on KOT49H too. But this guy's phone updated to KOT49N and this build was done on January 10. So I asked him about this and I'm waiting for his answerHi,
But if I'm not wrong 4.4.2 is only KOT49H?
https://developers.google.com/android/nexus/images#hammerhead.
H
Hammer_Of_The_Gods
Guest
Re,
Ah...
This, is read from the build.prop, so it "can" be edited...
The baseband also is not the current one compared to the others...
Ah...
This, is read from the build.prop, so it "can" be edited...
The baseband also is not the current one compared to the others...
Last edited:
LG brought this phone for him for review and now he is using it as main handset and receive some updates from google. And I ask people if they received the same updates as him. Also I think you can't change the name of the kernel, like Google did. Yes, baseband updated.Re,
Ah...
This, is read from the build.prop, so it "can" be edited...
Last edited:
H
Hammer_Of_The_Gods
Guest
Hi. Yes I'm on KOT49H too. But this guy's phone updated to KOT49N and this build was done on January 10. So I asked him about this and I'm waiting for his answer
There were some bugs fixed and added to AOSP source on January 10th, so maybe this holds some relevance.
ART will not be enabled until the next major release. I highly doubt we will see it enabled in a bug fix release.
![Candy[MAN]](/data/avatars/s/2070/2070738.jpg?1600603135){kind=avatar}
Wonder if this release has the newest video drivers released by Qualcomm back on Jan 24th.
Release notes from this driver update:
•Add support for GL_EXT_multisampled_render_to_texture extension.
•Fix incorrect output with glReadPixels() on an FBO with a texture attachment which is a cubemap face.
•Fix incorrect lighting in the UBOTest example from the Adreno SDK. This fix addresses problems with scalar operations on UBOs.
•Performance enhancements for rasterizer discard.
•Performance enhancements for transform feedback.
•Fix issue with graphics driver being unable to find and load Adreno Profiler libraries.
•Cleaner handling for internal compiler error cases for UBOs.
•Faster rsGetElementAt() and rsSample() runtime performance for programs that access many Allocation objects.
•Improved stability when compiling complex RenderScript code.
•Allow a count of zero in calls to glDrawBuffers() as per spec.
•Fix errors in calculation of 2D texture array slice sizes for NPOT textures.
•Generate GL_INVALID_VALUE from glTexStorage2D() and glTexStorage3D() when width, height, or depth exceed supported size.
•Fix behavior of glGetFramebufferAttachmentParameteriv() to properly return GL_FRAMEBUFFER_DEFAULT for the default framebuffer instead of returning GL_NONE. (See OpenGL® ES Version 3.0 spec §6.1.13.)
•Change glCopyTexImage2D() to prohibit SNORM as a destination format, as per Table 3.15 of the OpenGL® ES Version 3.0 spec.
•Relaxed restrictions on the width and height parameters of glCompressedTexSubImage2D() to allow updates of 1x1 and 2x2 miplevels for ETC2/EAC formats. The incoming data buffer must still have its width and height padded to four, as required by ETC2/EAC, but the width and height parameters to the function call may reflect the actual texture dimensions.
•Fix a potential double-free of memory inside glLinkProgram().
•Fix reported value of gl_MaxVertexTextureImageUnits for GLES 3.0 hardware.
•Add support for the following built-in constants in GLSL 3.0:
◦gl_MaxVertexOutputVectors
◦gl_MaxFragmentInputVectors
◦gl_MinProgramTexelOffset
◦gl_MaxProgramTexelOffset
•Fix transposition of u and v coordinates in GLSL textureOffset() and texelFetch() functions.
•Fix loss of w coordinate in GLSL textureOffset() and texelFetch() functions.
•Fix GLSL matrix constructor to accept an array of matrices.
Release notes from this driver update:
•Add support for GL_EXT_multisampled_render_to_texture extension.
•Fix incorrect output with glReadPixels() on an FBO with a texture attachment which is a cubemap face.
•Fix incorrect lighting in the UBOTest example from the Adreno SDK. This fix addresses problems with scalar operations on UBOs.
•Performance enhancements for rasterizer discard.
•Performance enhancements for transform feedback.
•Fix issue with graphics driver being unable to find and load Adreno Profiler libraries.
•Cleaner handling for internal compiler error cases for UBOs.
•Faster rsGetElementAt() and rsSample() runtime performance for programs that access many Allocation objects.
•Improved stability when compiling complex RenderScript code.
•Allow a count of zero in calls to glDrawBuffers() as per spec.
•Fix errors in calculation of 2D texture array slice sizes for NPOT textures.
•Generate GL_INVALID_VALUE from glTexStorage2D() and glTexStorage3D() when width, height, or depth exceed supported size.
•Fix behavior of glGetFramebufferAttachmentParameteriv() to properly return GL_FRAMEBUFFER_DEFAULT for the default framebuffer instead of returning GL_NONE. (See OpenGL® ES Version 3.0 spec §6.1.13.)
•Change glCopyTexImage2D() to prohibit SNORM as a destination format, as per Table 3.15 of the OpenGL® ES Version 3.0 spec.
•Relaxed restrictions on the width and height parameters of glCompressedTexSubImage2D() to allow updates of 1x1 and 2x2 miplevels for ETC2/EAC formats. The incoming data buffer must still have its width and height padded to four, as required by ETC2/EAC, but the width and height parameters to the function call may reflect the actual texture dimensions.
•Fix a potential double-free of memory inside glLinkProgram().
•Fix reported value of gl_MaxVertexTextureImageUnits for GLES 3.0 hardware.
•Add support for the following built-in constants in GLSL 3.0:
◦gl_MaxVertexOutputVectors
◦gl_MaxFragmentInputVectors
◦gl_MinProgramTexelOffset
◦gl_MaxProgramTexelOffset
•Fix transposition of u and v coordinates in GLSL textureOffset() and texelFetch() functions.
•Fix loss of w coordinate in GLSL textureOffset() and texelFetch() functions.
•Fix GLSL matrix constructor to accept an array of matrices.
Last edited:
I don't expect it will otherwise we'd see a bump in build number and anyway I hope not at least not until or even if Xposed becomes compatible. As much as I like the improvements ART brings I prefer my Xposed mods applied.
People seem to forget that despite moving the ART change to the master branch, it may very well be excluded/reverted in future final builds. Just remember the camera changes that were excluded from the KitKat update.
So don't blame Google if ART is not the default runtime in the next version. I can already see those "this is not a complete update..." , "Google failed to deliver" ... comments being thrown around
So don't blame Google if ART is not the default runtime in the next version. I can already see those "this is not a complete update..." , "Google failed to deliver" ... comments being thrown around
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
11
ART will not be enabled until the next major release. I highly doubt we will see it enabled in a bug fix release.1People seem to forget that despite moving the ART change to the master branch, it may very well be excluded/reverted in future final builds. Just remember the camera changes that were excluded from the KitKat update.
So don't blame Google if ART is not the default runtime in the next version. I can already see those "this is not a complete update..." , "Google failed to deliver" ... comments being thrown around
