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

graphics/java/android/graphics/Paint.java

@@ -674,10 +674,15 @@ public class Paint {
      * Return the pointer to the native object while ensuring that any
      * mutable objects that are attached to the paint are also up-to-date.
      *
+     * Note: Although this method is |synchronized|, this is simply so it
+     * is not thread-hostile to multiple threads calling this method. It
+     * is still unsafe to attempt to change the Shader/ColorFilter while
+     * another thread attempts to access the native object.
+     *
      * @hide
      */
     @UnsupportedAppUsage
-    public long getNativeInstance() {
+    public synchronized long getNativeInstance() {
         long newNativeShader = mShader == null ? 0 : mShader.getNativeInstance();
         if (newNativeShader != mNativeShader) {
             mNativeShader = newNativeShader;