rsnContextSetSurfaceTexture() has no implementation in rs-jni, use nContextSetSurface() in setSurfaceTexture().
Change-Id: I066432575c9e74f21ea3a3776628b572b6e31377
Signed-off-by: Xiaofei Wan <xiaofei.wan@intel.com>
Issue: Unable to turn off Airplane mode from power button
after phone reboot
Fix: Initialize mHasTelephony before the PhoneStateListener is
registered to the TelephonyManager so that correct value
of mHasTelephony is reflected when onServiceStateChanged
callback is called.
Bug: 13697360
Change-Id: Ide8afd9c16ea90b98b5912dbff440c5fd67b178d
* commit 'd511bc17d614b1291f1b85f84180c1db157d2790':
[ActivityManager] Fix a bug: unable to start activity after starting activities during screen off.
* commit 'ff3362f0d8378d616f39cbcf8b86b6f03e7d30b9':
DO NOT MERGE - [ActivityManager] Ensure consistency behavior when a background activity brings another existed activity to front.
Perform the relabel of the /data/data/<pkg> directories
when the app is being scanned by the PMS. The impetus
for this change was that the data directories of forward
locked apps were receiving the wrong label during an
OTA. Because the PMS doesn't actually scan forward locked
apps til later in the boot process, the prior restorecon
call was actually applying the default label of
system_data_file for all such apps. By performing a
restorecon on each individual app as they are entered into
the PMS we can handle them correctly. This mechanism also
allows us to pass down the seinfo tag as part of the
restorecon call which drops our need to rely on the contents
of packages.list.
Change-Id: Ie440cba2c96f0907458086348197e1506d31c1b6
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>
Use LOCAL_MULTILIB := both to build app_process64 instead of
duplicating the build rule.
Also causes PRODUCT_PACKAGES := app_process to install both
versions on 64-bit platforms, as the module names for both
app_process and app_process64 are now app_process.
Change-Id: Ia3c3265d15475771b0cae8bace53b8fbf351c186
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>
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
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
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
