[Resources] fix preload drawables low issue

Symptom: preload drawables too few
Root Cause: verifyPreloadConfig() function not correct. We need to
convert the config to native config and mask the 0x40000000 bit.
Solution: correct the verifyPreloadConfig() function.
Project: AOSP
Note:

Change-Id: I63eb2a7bf50c89fcb37e62423aae8f4f7e81c6aa
[AssetAtlas]: Fix AssetAtlas not consider all size of texture.

Symptom:
Atlas service get exception because the result is null.

Root Cause:
The original logic will miss the largest width in each thread.
Take two processors as an example, first thread will miss 2048, second thread will miss 1984.
With some condition, only 2048*2048 or 1984*2048 can exceed the mThreshold.
In this case, the mResults is empty and cause crash when trying to use the first result.

Solution:
Adjust the boundary and the condition so that it can consider all size of texture.

Change-Id: Id54de57cd1501ed7355f2237f05726d2965aed6d
[AssetAtlas] Avoid packing 1-pixel width or height asset into AssetAtlas

Symptom: For preloaded asset which has 1-pixel width (or 1-pixel height),
         sampling the atlas texture will get a color mixed with the surrounding
         pixels' color.
         If we have padding in the atlas texture , sampling will mix the
         padding's black color and result in an obvious defect.

Solugion: We avoid packing 1-pixel width (or 1-pixel height) asset into
          AssetAtlas.

Change-Id: I765673dfa13cf3f3709196cf15f35d3493d1edd8
[ActivityManager] Fix race condition in pss collection

Symptom:
There has a race condition that two threads are accessing
the mPendingPssProcesses simultaneously. One of the thread
is collecting the process pss by looping the mPendingPssProcesses.
The other thread is requesting to collect pss of all processes,
which clears mPendingPssProcesses and adding processes back.

Solution:
Avoid race condition by adding synchornized protection.

Change-Id: Ifb090eda9c4a1b8e3fd980fe0171e9dd77773b46
[ActivityManager] Finish the failed-to-pause activity

Symptom:
In some scenario, the mPausingActivity may be replaced by other activity.
When previous activity paused, the completePausedLocked() won't be invoked
because it is no longer the mPausingActivity. If the activity is also
pending to finish, it would never be done because the activity kept in
PAUSING state. Since the activity's window also remain visible and is
above on Wallpaper, user would see it when back to home.

Solution:
Finish the failed-to-pause activity if the activity is pending to finish

A Real Case:
(1) Screen turn off
(2) The top activity T1 crashed
(3) When finish activity T1, the next top activity T2 will be scheduled
    to resume and pause (due to screen off).
(4) The activity T2 is also set to finishing due to T1 crashed.
(5) Before T2 paused and before paused timeout occurs, there has a new
    process started which brings up the next top activity T3 to resume
    and pause. So the pausing activity is now replaced.
(6) When activity T2 paused, it cannot completed the pause operation.
    T2 will remain in PAUSING and finishing state with its window visible.
    The process won't be killed because the oomadj stays at 1 (Visible).

Change-Id: Ib10fded891b21c774b26a93071c717fa50516e22
[ActivityManager] Fix ServiceRecord leakage

Symptom:
The first step of cleaning up application services is
to clear the app state from services (which set sr.app
to null). Then it clean up the service connections.
In some scenario, the Service might be removed during
the connection cleanup (i.e. the Service is no longer
needed). In that case, the Service will be removed from
ServiceMap, but won't be removed from r.app.services
(line 1612) because the r.app is null.

Solution:
Remove the service connection first.

Change-Id: I644d73af58fe0e7c1c4a6c9779fe6b5d747b880d
[ActivityManager] Ensure provider external access count will be released.

Sympton: Oom-adj of provider process will be always 0.

Root Cause: Exception happend in openContentUri
may not call removeContentProviderExternalUnchecked.

Flow:
application [MediaPlayer.setDataSource(Context context, Uri uri)]
    uri is invalid, IOException will be caught and below log will appear:
    "Couldn't open file on client side, trying server side"
    Continue to call setDataSource(String path, Map<String, String> headers)
 ->mediaserver [MediaPlayerService::Client::setDataSource]
    setDataSource(httpService, url, headers) calls openContentProviderFile
 ->system_server (ActivityManagerService) [openContentUri]
    Increase externalProcessNoHandleCount for media provider.
    Call [openFile] to media provider.
 ->android.process.media [check permission for openFile]
    enforceReadPermissionInner
 ->system_server [checkComponentPermission]
    Use mediaserver's uid to check READ_EXTERNAL_STORAGE
      -> not granted due to it is pure native process, not a known package.
    Throw security exception then the flow of openContentUri is broke.
    And externalProcessNoHandleCount is unable to decrease.

Application sample code:
 String invalidId = "54321";
 Uri externalUri = MediaStore.Files.getContentUri("external");
 Uri uri = Uri.withAppendedPath(externalUri, invalidId);
 mediaPlayer.setDataSource(mContext, uri);

Solution: Move removeContentProviderExternalUnchecked to finally block.

Change-Id: I75eec1f9631e9c6bb18449946d707d51ac21e8a7
[ActivityManager] Fix NullPointerException when dumping ContentProviderRecord.

Sympton: If there is external access without handles, dumpsys will met exception as:
  * ContentProviderRecord{45ed0fc8 u0 com.android.providers.media/.MediaProvider}
...
    externals=
Exception occurred while dumping:
java.lang.NullPointerException
	at com.android.server.am.ContentProviderRecord.dump(ContentProviderRecord.java:171)

Root Cause: External handles may be empty but there is "no handle" count.

Solution: Check null and print with handle, no handle count.

Change-Id: I0ee497096113e5685d491a0d4346f57d398495e6
[ActivityManager] Prevent provider creating twice.

Root Cause:
If a process which contains provider is starting by not
from accessing provider, e.g. service/activity/receiver,
its providers' will be created during handleBindApplication.
And before the process complete publish provider to
ActivityManagerService, if there is an access to its provider,
these providers will be created again (there will have 2nd onCreate).

Solution:
Check if provider record is existed, do not schedule install provider,
becuase it is already creating and will be published later.

Change-Id: Ic200ceae042c014c86e7edee0acd013b513af334
[ActivityManager] Fix index out of bounds when updating next pss time.

Symptom:
System server crash.

Root Cause:
The value curProcState for array index is -1 if the process has not attached yet.

Solution:
Skip compute for process which is not attached or have invalid curProcState.

Change-Id: I71aaf45bb78d73097ebe9dfebf76b72f2d243232
ContentProvider: Avoid duplicate initialization of AsyncTask

AsyncTask is being initialized by ActivityThread to ensure its static
handler initilization and ContentProvider need not duplicate the logic.

Change-Id: I48bc88bdba32b56114f09c04a75480e26508f704
[HWUI] The IBO state should be reset after glDeleteBuffers.

Symptom:
Can't bind to correct IBO.

Root Cause:
If a buffer object that is currently bound is deleted by glDeleteBuffers, the binding reverts to 0.
This may cause bindIndicesBuffer doesn't work if mCurrentIndicesBuffer not reset to 0.

Solution:
Reset mCurrentIndicesBuffer to 0 after glDeleteBuffers.

Change-Id: Iecd3ded76d876fcadde89a8893bab5f75b1eb312
[HWUI] Infinite recursion in PathTessellator::recursiveQuadraticBezierVertices()

Symptom: In some cases like the distance between the calculating point is very
         small, the recursion may not terminate.
         If the calculated dx and dy are 0, d is 0 too. Then the termination
         condition(d*d < TH*TH*(dx*dx*sq + dy*dy*sq)) will never be met.
         Infinite recursion will cause stack-overflow.

Solution: We added one more threshold to terminate the recursion when d is very
          small (possibly 0).

Change-Id: I7d27a72811109766766f8f8cc5d8d88e75db7f60
[HWUI]: Bind wrong VBO when drawing text

Symptom:
We should not set mDrawn to true if we have no GL draw call.

Root Cause:
In some case, issueDrawCommand may executed without GL draw call.
It may miss the unbindMeshBuffer in the next issueDrawCommand and the status of VBO of FontRenderer will incorrect.

Solution:
Add condition to check if have draw call.

Change-Id: I9e96cd0334c515172b0ed6c25b101c81cf6d2e6f