idmap --scan is executed as a part of the pre-loading in ZygoteInit.
The pre loading is executed in parallel for each supported architecture
(32/64 bit). This will cause a race condition in the creation of the
overlays.list file and the idmap files for the system overlays.
Apply flock on overlays.list to prevent the file from being thrown away
and recreated when it is in use by another Zygote.
Bug: 28032298
Change-Id: I51d39f121d207b11181340b68b164b60020f0c61
This CL fixes a SkShader leak in VD when applying local matrix
to the shader. Specifically, the usage of newWithLocalMatrix(...)
increments the shader's ref count in every draw() call for
Gradient VectorDrawable, whereas there's no balancing call to
decrement the ref count in draw(). In this CL, we assume
the ownership of the shader returned from newWithLocalMatrix(...)
to ensure the correct ref count management.
Also, add test to verify that shader is no longer being leaked
BUG: 32067647
Test: this CL
Change-Id: Ic15fe46cde06a73d81b44e2d3c56b51907344cc0
Bug: 29628138
1: Make windowPositionLost synchronous as that's
what the Java side was expecting
2: Make the listener ref counted as otherwise
there's a race condition with the GC, which could
end up with use-after-frees
3: Ensure that all position updates are invoked
prior to frame completion
Change-Id: Iedbc017f611ba2878a49b4586612f79249ca2fe3
(cherry picked from commit 7b570deea65bc7ac417a26ce3e4103bcef30e957)
This CL fixed an issue where calling start() from onAnimationFinished()
caused AnimationListenerBridge::onAnimationFinished(...) to be unsafely
re-entered and the new start listener was (incorrectly) reset to null.
BUG: 31971397
Test: test apk in the bug linked above
Change-Id: Ica809ef2dab884950b93b54f2d0cb4b81e9830f1
The SharedZip's Asset is not thread-safety,the getResourceTableAsset()
and setResourceTableAsset(Asset* asset) function of the SharedZip is
not sync with a same lock.
Consider the following sequence of events:
Thread A calls setResourceTableAsset(Asset* asset),it will set
mResourceTableAsset = asset; then to calls getBuffer() of the asset.
Thread B calls getResourceTableAsset(),which return mResourceTableAsset,
then to calls getBuffer() of the mResourceTableAsset,the asset and
mResourceTableAsset is same one object.
Thread A to delete mZipInflater in getBuffer().
Thread B to delete mZipInflater in getBuffer().
It will cause crash becuase double delete mZipInflater in getBuffer().
https://code.google.com/p/android/issues/detail?id=211941
Bug:31734545
Change-Id: I5a7d67fdf64c4aa03f505b37a2fa840f4443d158
Signed-off-by: songjinshi <songjinshi@xiaomi.com>
See go/sku-colors. This changes the directory to search for framework
overlays if the right system property is defined. This allows
OEMs to specify different resources based on device SKUs.
Bug: 31692079
Change-Id: I9cb121b286b7f52aa26de1757fde1f3110cd47fd
The maximum length of a system property is 31 bytes.
debug.hwui.enable_partial_updates is 33 bytes
Change-Id: Idb1b1a00294dd29f84530e8aee1f685094d0096f
The SharedZip's Asset is not thread-safety,the getResourceTableAsset()
and setResourceTableAsset(Asset* asset) function of the SharedZip is
not sync with a same lock.
Consider the following sequence of events:
Thread A calls setResourceTableAsset(Asset* asset),it will set
mResourceTableAsset = asset; then to calls getBuffer() of the asset.
Thread B calls getResourceTableAsset(),which return mResourceTableAsset,
then to calls getBuffer() of the mResourceTableAsset,the asset and
mResourceTableAsset is same one object.
Thread A to delete mZipInflater in getBuffer().
Thread B to delete mZipInflater in getBuffer().
It will cause crash becuase double delete mZipInflater in getBuffer().
https://code.google.com/p/android/issues/detail?id=211941
Change-Id: I5a7d67fdf64c4aa03f505b37a2fa840f4443d158
Signed-off-by: songjinshi <songjinshi@xiaomi.com>
Currently PointerController starts listening to display events
immediately (in its constructor) and never explicitly removes
the callback. The reference dangling from the looper
prevents the PointerController instance from being deleted
when all the clients have released their references.
As a result, when USB or BT mouse is disconnected,
the mouse stays frozen on screen and only goes away
after a 15 sec inactivity timeout.
This change introduces an intermediary LooperCallback
which holds only a weak reference to PointerController.
The pointer now disappears immediately upon mouse
disconnect.
Bug: 30824220
Change-Id: I5f7208dbfa381b3e21f248cc0da402f307faa184
bug:30895941
Prevents a race where frame work could interleave between frames,
causing SurfaceView position updates to be delivered out of order.
Change-Id: I01e4cc557b69dcf33e877a0e16c0d115ec95e4cc
