Remove duplicate call disconnect codes.

The Android code base defines call disconnect codes in three places:
 - android.telephony.DisconnectCause
 - android.internal.telephony.Connection.DisconnectCause
 - com.android.services.telephony.common.Call.DisconnectCause

This CL consolidates the code to use the integer codes from
android.telephony.DisconnectCause everywhere.

Change-Id: I84a3fd5182a51d07fc7d81076e4b2c15ff26c61c
[ActivityManager] Fix a bug: unable to start activity after starting activities during screen off.

Symptom: Unable to start any activity.
Root Cause: ActivityStack.mPausingActivity() points to a destroyed activity of a died process, so that ActivityStackSupervisor.allPausedActivitiesComplete() always returns false.
Solution: Set mPausingActivity to null in ActivityStack.cleanUpActivityLocked().
Reproduce steps:
    a. Turn screen off.
    b. A background service starts an activity X (in process X).
    c. A background service starts a no-history activity Y (in process Y), but the main thread of Y was blocked.
    d. A background service starts Y 3~4 times --> this causes am_failed_to_pause on X.
    e. Main thread of Y is freed finally --> this causes Y crash for android.view.WindowManager$BadTokenException.
    f. Turn screen on, X is shown on screen, but neither back key nor home key can work because mPausingActivity is Y.

Change-Id: I320b3db407e2d4cc745c8ca22a6e548742234242
Reduce warning verbosity in aapt

- Attributed source of problems to the correct file.
- Only verify string localizations against valid
  locales.
Bug:13140015
Change-Id: I9dabc5efa0510649caee8af0c8ebb803d6f48269
Use X509ExtendedTrustManager and not Conscrypt

This allows the new X509ExtendedTrustManager to be used instead of
Conscrypt directly.

Bug: 13103812
Change-Id: I736f475342395f26657f2371828a6d3a0065a50a
Solve three memory leaks related to PatchCache

A Patch can be fairly large, holding bitmap data, but
is also frequently leaked which adds to the severity.
The feature is used in many important processes such
as Home, SystemUI and Chrome.

The following leaks are solved:

1. The Patch itself was not always freed.
PatchCache::removeDeferred() can mark patches to be
cared for by PatchCache::clearGarbage(). But
mCache.remove() would only destroy the container
and the pointer, not the Patch object itself.

2. The vertices stored in the Patch at Patch::createMesh()
would always leak. The empty/default destructor in Patch
would not properly destroy "vertices" since it's just a
pointer.

3. A BufferBlock that's added to the mFreeBlocks
in PatchCache could leak. The leak happened when a
patch later needed the entire free block, because the
object was removed from the list but never deleted
in PatchCache::setupMesh().

Change-Id: I41e60824479230b67426fc546d3dbff294c8891f
Don't wait for finishing animation when second display is disconnected

Basically WindowManagerService wait for finishing animation when
a window is removed. But when second display is disconnected, windows
on second display can't be shown even if animation is waited for.
On the contrary, it keeps on waiting for finishing the animation
in special case.

With this fix windows are immediately removed without waiting for
animation when second display is disconnected.

Change-Id: I1354c193c04db394a21a11c174e10c8e7da17a0e
Cast CallMethod's size_t parameters to jint

This will avoid problems caused by automatic type
promotion of parameters when passed to a variadic function.

Change-Id: I9340cf4bc3afcb84ebb2843d2aaa1e832b0df7f4
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Merge "Don't wait for finishing animation when second display is disconnected"
Merge "Use X509ExtendedTrustManager and not Conscrypt"
Merge "Solve three memory leaks related to PatchCache"
DO NOT MERGE - [ActivityManager] Ensure consistency behavior when a background activity brings another existed activity to front.

Symptom: ANR occurs on previous activity.
Root Cause:
In KK, when a background activity starts another existed background activity (bring to front),
if current focused stack is not the same as the stack of target starting activity,
it will still resume the top of target stack, even the top activity on the target stack may not the same as target activity.
And it will result incorrect focus, press back key will send to previous stack's top then popup ANR on previous activity:
"Reason: Waiting because no window has focus but there is a focused application".

By original code comment, it looks 'bring to front' should not happen in this issue case.
// If the target task is not in the front, then we need
// to bring it to the front...  except...  well, with
// SINGLE_TASK_LAUNCH it's not entirely clear.  We'd like
// to have the same behavior as if a new instance was
// being started, which means not bringing it to the front
// if the caller is not itself in the front.

If the caller and target are in the same stask, it will just deliver new intent without changing task order (the same behavior as JellyBean).
So the patch concept is just to avoid to use target stack to resume top when caller and target are in different stack.

Solution: Do not allow to resume another stack top if non-top activity try to bring existed activity to front.
It may not be a good solution, just a reminder for the issue case.

Reproduce steps:
Assume A, B, C are different app tasks.
When the application stack is like:
  Top C
      B
      A

 #Case 1: Home is foreground
  A starts B with NEW_TASK, C will resume, focus still stays at Home, and window order does not update.
  Then press back key or volumn key will result ANR on Home.

 #Case 2: App is foreground (Resumed activity is C)
  A starts Home, Home will resume, focus still stays at C, and window order does did not update.
  Then press back key or volumn key will result ANR on C.

Change-Id: If05070123b248e2335791e43a4d4ddee6db11d84
Note libselinux dependency on packages.list format changes.

Change-Id: I3c34a86f5706c4fca826a8634936131e4e4fc297
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
CertificateChainValidator: initialize TrustManagerFactory

Need to call TrustManagerFactory#init before use. I suspect this class
isn't used anywhere since this hasn't caused a problem yet.

Change-Id: I17425d0bba4795d71960062361a755830abba7de
Merge "Note libselinux dependency on packages.list format changes."
jni: 64-bit compile issue

- switch to PRId64
- some unused parameter warning suppression

Change-Id: Ia36bd1a247bb6e866a6b1050ab1362ebc9d31786
Merge "jni: 64-bit compile issue"
Merge "CertificateChainValidator: initialize TrustManagerFactory"
Do not show Home behind full screen activity

When ensureActivitiesVisibleLocked goes through foreground activity
stack and reaches non-fullscreen activity, it sets showHomeBehindStack
variable to true.

If there is a fullscreen activity behind, showHomeBehindStack remains
unchanged, which causes Home application to be displayed anyway.
In this case user will see a fullscreen activity and Home activity
simultaneously.

To fix the issue we set showHomeBehindStack to false when we reach
fullscreen activity in the activity stack.

This was made visible by the following commit:
446ef1de8d373c1b017df8d19ebf9a47811fb402

Change-Id: I535c1283a4e26f5cf606375b837d4b7195324af0
AArch64: Make frameworks/base code more portable

Changes in this patch include

[x] Use %zu for size_t, %zd for ssize_t

[x] Some minor changes have been done to conform with
    standard JNI practice (e.g. use of jint instead of int
    in JNI function prototypes)

Change-Id: Id1aaa7894a7d0b85ac7ecd7b2bfd8cc40374261f
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Craig Barber <craig.barber@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Merge "AArch64: Make frameworks/base code more portable"