diff options
| author | Leon Scroggins III <scroggo@google.com> | 2020-06-30 14:50:06 -0400 |
|---|---|---|
| committer | Leon Scroggins III <scroggo@google.com> | 2020-07-16 09:25:33 -0400 |
| commit | 69b95fa2a55f773576522558e295347da85e3ddf (patch) | |
| tree | 61d9fdba9da22e698101065f6b5bcad704ef2e4b /tools/aapt2/java/JavaClassGenerator.cpp | |
| parent | d732652c9c1d648a00de98cf7d5f87653bf16496 (diff) | |
Make Paint/Shader/ColorFilter#getNativeInstance conditionally thread-safe
Bug: 159246162
Bug: 154358781
Test: PaintNativeInstanceTest.kt
Although the android.graphics package makes no promises regarding
thread-safety, it is not obvious to clients how they might call
getNativeInstance from multiple threads. If one thread sets up a Paint,
and then two threads use it, this sets up a race condition for setting
up the native SkPaint. This seems to have been observed in internal
apps. Put accesses and modifications to these native objects inside
a synchronized block, so that we don't end up with a situation where
two instances of mCleaner attempt to dereference the same native object.
Add tests in PaintNativeInstanceTest.kt
Change-Id: I10fa0958ea216bfbc79667c6217dd6570b3eb110
Diffstat (limited to 'tools/aapt2/java/JavaClassGenerator.cpp')
0 files changed, 0 insertions, 0 deletions