51c70e3e41ee8bedc1d951a06a74202dafa13009
this situation happened when the last buffer needed to be resized (or allocated, the first time). the assumption was that the buffer was in use by SF itself as the current buffer (obviously, this assumption made no sense when the buffer had never been allocated, btw). the system would wait until some other buffer became the "front" buffer. we fix this problem by entirely removing the requirement that the buffer being resized cannot be the front buffer. instead, we just allocate a new buffer and replace the front buffer by the new one. the downside is that this uses more memory (an extra buffer) for a brief amount of time while the old buffer is being reallocated and before it has actually been replaced. Change-Id: I022e4621209474ceb1c671b23deb4188eaaa7285
am
38137d7a: Merge "docs: lots of additions to the resources docs new drawable resources add <merge> and <include> to layout resource update drawable class descriptioons to point to resources guide add ID resource type" into froyo
Description
No description provided
Languages
Java
73.7%
Kotlin
14%
PowerBuilder
5.8%
C++
5.2%
AIDL
1%