frameworks-base

Fork

Fix KW issues on PRC compatibility

Fix KW issues on PRC compatibility,introduced by below commit.
https://android.intel.com/#/c/484542/

Change-Id: Ib10899655dd2a18569387dbafbe33856acf5df59
Tracked-On: https://jira01.devtools.intel.com/browse/OAM-26904
Signed-off-by: jgu21 <jinghui.gu@intel.com>
Reviewed-on: https://android.intel.com:443/487804

Reduce the overhead of the PRC compatibility package feature during system bootup

The PRC compatibility package introduced too heavy overhead
in system bootup. This commit aims to reduce the overhead
in system bootup and improve the performance of PRC
compatibility package.

NOTE: The format of ThirdPartySO has been changed to improve
the performance. From now on, the lib name should be trimmed
as below if want to add into the list. For "libabc_v1_2_3.so",
add "abc_v" into the list, that is, the version information
at the tail of lib name should be removed.

Change-Id: Ic374e363d3d31f9bd69be839b33b1bd65950ef61
Tracked-On:https://jira01.devtools.intel.com/browse/OAM-25819
Signed-off-by: xiajiang <xia1.jiang@intel.com>
Reviewed-on: https://android.intel.com:443/484542

Enable the PRC compatibility package feature for PRC market

In PRC market, some APKs are packed in non-standard way, that is,
the x86(_64) libraries aren't workable although they're found in the APK.
This patch intends to relieve the impact from below 2 defects,
which is based-on the heuristic algorithm.

NOTE: To enable this feature, set "PRC_COMPATIBILITY_PACKAGE := true"
in device BoardConfig.mk before enabling houdini.

1. Missing x86(_64) libraries: The x86(_64) libraries are ported and
existing in the APK. But it's incomplete, and not workable.
2. Mixed arm(64) libraries: Several libraries are existing in lib/x86(_64)/
directory in the APK. But some of them are arm(64) libraries,
instead of x86(_64) ones.

All of above always cause APP crash if installed x86(_64) libraries
by PackageManager.

This patch aims to improve PackageManager to figure out these defects
and install arm(64) libraries to run the APP with houdini support.
The basic idea is to compare x86(_64) libraries with arm(64) alternatives
to determine which one should be workable.

To customize it for specific APPs, 3 lists are provided under
/system/vendor/etc/misc/ on the device.

1. /system/vendor/etc/misc/.OEMWhiteList:
This patch will be disabled for the APPs containing in the OEMWhiteList
2. /system/vendor/etc/misc/.OEMBlackList:
The APP is enforced to install the arm(64) libraries if existed.
3. /system/vendor/etc/misc/.ThirdPartySO:
This is another list which contains the names of all 3rd-party libraries,
which will impact on the final decision of APP installation.

Change-Id: I2613d9ebc8fe012c801f4a38fc5dede413f15a91
Tracked-On: https://jira01.devtools.intel.com/browse/OAM-20470
Signed-off-by: xiajiang <xia1.jiang@intel.com>
Reviewed-on: https://android.intel.com:443/471490

fd_utils: fix DEBUG mode booting issue (pie-x86)

Porting to pie-x86 codebase of oreo-86 commit
c283ba107a ("fd_utils: fix DEBUG mode booting issue")

Original commit message:

Remove the "/android/" prefix before the white list checking.

Suggested by Chris Vandomelen <chris@sightworks.com>.

Camera: ignore exceptions from getSupportedPreviewFpsRange

input: simulate long press properly

The original implementation of long press sends two ACTION_DOWN events
which would be interpreted as a double tap. For example, sending
a long press POWER key will launch the camera:

11-21 16:27:37.320 2223 2223 I Input : injectKeyEvent: KeyEvent { action=ACTION_DOWN, keyCode=KEYCODE_POWER, scanCode=0, metaState=0, flags=0x0, repeatCount=0, eventTime=39641, downTime=39641, deviceId=-1, source=0x101 }
11-21 16:27:37.321 2223 2223 I Input : injectKeyEvent: KeyEvent { action=ACTION_DOWN, keyCode=KEYCODE_POWER, scanCode=0, metaState=0, flags=0x80, repeatCount=1, eventTime=39641, downTime=39641, deviceId=-1, source=0x101 }
11-21 16:27:37.322 1411 1565 I GestureLauncherService: Power button double tap gesture detected, launching camera. Interval=0ms
11-21 16:27:37.322 2223 2223 I Input : injectKeyEvent: KeyEvent { action=ACTION_UP, keyCode=KEYCODE_POWER, scanCode=0, metaState=0, flags=0x0, repeatCount=0, eventTime=39641, downTime=39641, deviceId=-1, source=0x101 }

This is unexpected and incorrect.

Just simulate the long press by delaying ACTION_UP one second.

DiskInfo: support CD/DVD type

Detect HDMI audio by switch events

If detect SW_VIDEOOUT_INSERT, assume HDMI is plugged.

Support save local time to RTC

Make it work for dual boot with Windows, we could set property
persist.rtc_local_time to 1, so that RemixOS and Windows both
use local time in rtc.

NO_REF_TASK
Tested:
1) set time in android, reboot to bios, make sure the time in bois is
local time
2) reboot back to android, the current time should be correct local time
(this need another change)

Change-Id: Id2c0ce150fb9320b132ad8bdd83b38dcae1070db

Map keycode 120 to APP_SWITCH

Define the unused keycode 120 to be APP_SWITCH.

InputReader: read the pointercal from TSCalibration2

Watch the pointercal and reload it on changed.

Make "windows" key to act as "home" key

Issue: AXIA-1893
Change-Id: I7b2b19f7e34ec8a1867e8e6ce522e65133e5267f
Signed-off-by: juntingwang <Junting.Wang@windriver.com>

camera: fix NullPointerException

GLSurfaceView: Be less picky about EGLConfig alpha sizes

EGLChooseConfig returns a "best match" set of visuals meeting or
exceeding the required r/g/b/a component depths. But GLSurfaceView
oddly requires that the returned visual be an exact match. Add to
that that the (rarely used outside of CTS) default request specifies
zero alpha bits and that not all drivers expose a zero-alpha
EGLConfig, and the default configuration will fail needlessly.

It's not incorrect to have alpha bits you didn't request: the only way
to produce divergent behavior is for a fragment shader to write out
explicit alpha values (into the channel it didn't want to begin with!)
with values other than 1.0 and then rely on them being ignored and
treated as 1.0.

For: AXIA-1448
Change-Id: I2f64995d7b9de1ae082aa47822af525390102083
Signed-off-by: Andy Ross <andy.ross@windriver.com>

import YuvToEncoder R3 patches, BZ 18528, 19092, 19696

BZ: 47824

Please refer http://umgbugzilla.sh.intel.com:41006/show_bug.cgi?id=19092 and
external/jpeg/libjpeg.doc

The MCU height is max_v_samp_factor = 2 DCT rows so you must pass at least 16
scanlines on each call to jpeg_write_raw_data(), which is to say 16 actual
sample rows of Y and 8 each of Cb and Cr.

The original implement of Yuv420SpToJpegEncoder::compress didn't add padding to the frame buffer
when height and width aren't aligned with 16 pixel. It will cause illegal memory violation and core dump.

Category: aosp improvement
Domain: Video.Media-jpeg
Origin: Internal
Upstream: Yes

Change-Id: Ibcf14230d616e2d440ace244bb420723b5c01dc2
Orig-Change-Id: Ic1b7494b98ee9c1997b226d58abd034b1dcb18f6
Signed-off-by: Tong, Bo <box.tong@intel.com>
Signed-off-by: Zhao Liang <leo.zhao@intel.com>

Fix potential double destroy of AssetManager

Assume there is a XmlBlock [X] created by a AssetManager [A]
([A] will have mNumRefs = 2). After [A].close is called
(mNumRefs = 1) and then both [X] and [A] are going to be GCed,
if [A].finalize is called first (nativeDestroy), the later
[X].finalize will invoke [A].xmlBlockGone that triggers the
second nativeDestroy of [A] and leads to crash.

By clearing the mObject in AssetManager.finalize, the
decRefsLocked from other paths won't call nativeDestroy again.

Bug: 144028297
Test: atest android.security.cts.AssetManagerTest

Change-Id: Ia938502d2443f5a6de6a3cabdb7ce1d41d3ff6d1
Merged-In: Ia938502d2443f5a6de6a3cabdb7ce1d41d3ff6d1
(cherry picked from commit 93320661ca9a23c7b38b3f166d0facf048f2a8a3)

Revoke 'always' web handler status when not autoverifying

If an app has previously used autoVerify to make claims about its status
re handling web navigation intents, but is updated such that it no
longer makes those claims, step down its "official handler" status as
though it had never invoked autoVerify in the first place.

Bug: 146204120
Test: manual: as described in bug; observe policy before/after via
'adb shell dumpsys package d'
Test: atest CtsOsHostTestCases
Change-Id: I58502d1b32d793aba9aa772fa2ad5ac38acca48a
Merged-In: I58502d1b32d793aba9aa772fa2ad5ac38acca48a
(cherry picked from commit 6cf5f92825df545bd011b7163418f2ea0b337af3)

RESTRICT AUTOMERGE Create separated tasks for different apps from startActivities

Assume there are 2 applications A, B with different uids.
There are 4 activities A1, A2, B1, B2 with default task
affinity and launch mode.

After A1 called startActivities(B1, A2, B2):
Original : Task(A1, B1, A2, B2)
This Change: Task(A1, B1), Task(A2, B2)
In other words, the source caller cannot launch its activity
above the activity of other application in the same task, and
it can still launch activity of other application in its task.

Bug: 145669109
Test: run cts --test android.server.cts.StartActivityTests \
-m CtsServicesHostTestCases
Change-Id: I97bd875146a52f62b8fe82235487ccefb2955e8e
(cherry picked from commit 973ecc619c0bb87a03481774ea9e86d2924601e4)

[Pie port] Add minimize & pip buttons to freeform windows

Thanks to @farmerbb for assistance and @rogerdott for the graphics

Change-Id: I8ddad6eab27f52574ee1c10e8006612fb46a83c5

Work around GMS crashing issue on 32-bit image

Android 8.1.0 release 74
-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRDQNE1cO+UXoOBCWTorT+BmrEOeAUCXl1q/wAKCRDorT+BmrEO
eB3XAJ9GV9tT451mn+k3rtrk7ltiQUQYtwCeKlzfAmAOoNuxlXq/Uy/2M+Rn2bs=
=gJGS
-----END PGP SIGNATURE-----

Merge tag 'android-8.1.0_r74' into oreo-x86

Android 8.1.0 release 74

Android 9.0.0 release 54
-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRDQNE1cO+UXoOBCWTorT+BmrEOeAUCXl2XogAKCRDorT+BmrEO
eHrcAJ9mj3yevhRcOAxx0NnlCWyt8b9b9QCeM0ceoMAF7+T4fiUlbJnifrKP4cw=
=b9fk
-----END PGP SIGNATURE-----

Merge tag 'android-9.0.0_r54' into pie-x86

Android 9.0.0 release 54

RESTRICT AUTOMERGE Use consistent calling uid and package in navigateUpTo

Originally, if the caller of navigateUpTo is alive, even the calling
uid is set to the caller who launched the existing destination activity,
the uid from caller process has higher priority to replace the given
calling uid. So this change doesn't modify the existing behavior if
the caller process is valid. Besides, the case of delivering new intent
uses the source record as calling identity too, so the case of starting
new activity should be consistent.

Also forbid attaching null application thread to avoid unexpected state
in process record.

Bug: 144285917
Test: atest ActivityStackTests#testNavigateUpTo
Test: atest CtsSecurityTestCases:ActivityManagerTest# \
testActivityManager_attachNullApplication
Change-Id: I60732f430256d37cb926d08d093581f051c4afed
(cherry picked from commit da78af4d6696dda77c692a7c6f2f49d4277cf341)

RESTRICT AUTOMERGE Create separated tasks for different apps from startActivities

Assume there are 2 applications A, B with different uids.
There are 4 activities A1, A2, B1, B2 with default task
affinity and launch mode.

After A1 called startActivities(B1, A2, B2):
Original : Task(A1, B1, A2, B2)
This Change: Task(A1, B1), Task(A2, B2)
In other words, the source caller cannot launch its activity
above the activity of other application in the same task, and
it can still launch activity of other application in its task.

Bug: 145669109
Test: atest StartActivityTests# \
testStartActivitiesWithDiffUidNotInSameTask
Change-Id: I97bd875146a52f62b8fe82235487ccefb2955e8e
(cherry picked from commit 48d8d370f3d1dac06719ca6a52bda5f45a1a533a)

DO NOT MERGE - Kill apps outright for API contract violations

...rather than relying on in-app code to perform the shutdown.

Backport of security fix.

Bug: 128649910
Bug: 140108616
Test: manual
Test: atest OsHostTests#testForegroundServiceBadNotification
Change-Id: I94d9de50bb03c33666471e3dbd9c721e9278f7cb
Merged-In: I94d9de50bb03c33666471e3dbd9c721e9278f7cb
(cherry picked from commit a79b6ba5c59dc6aaa8adbe1ffa3ee4b761f45e7f)

DO NOT MERGE Ensure package names read from config are system packages.

Bug: 145981139
Test: manually tested ensureSystemPackageName() returns null for non-system app
Change-Id: I1d23910cbd282f6702785c9dfb059d7be6b0e895
(cherry picked from commit 6a56247200e1a8afc4dacc2497ec384efa200b92)
(cherry picked from commit 584d73a0b066e01b0877b475c8e2b1a85fcf5328)

RESTRICT AUTOMERGE
Update keyguard locked state from TrustManagerService

TrustManagerService holds the ground truth about whether a user is
locked or not, so update keystore using the information there,
instead of doing it from KeyguardStateMonitor. This fixes the issue
of work profile locked state not being correctly pushed to keystore.

Note: since this change is likely to be backported as a security
patch, I'm refraining from doing major refactoring right now.

Bug: 141329041
Bug: 144430870
Test: manually with KeyPairSampleApp
Change-Id: I3472ece73d573a775345ebcceeeb2cc460374c9b
(cherry picked from commit 0860a5c5c303426073c36763bef28644673ff441)

Only suspend package from system or shell

Test: manual
Bug: 148059175
Change-Id: I50ee768e792266ad2091f1913168e89d5d1463ed
Merged-In: I50ee768e792266ad2091f1913168e89d5d1463ed
(cherry picked from commit 1c943a2670c1ff499669b42ef72dcd9f07db08c3)
(cherry picked from commit adc39de3a148a2058d63bd7a1b8b71ee0a3524ac)
(cherry picked from commit eb4f716bf3a0ee3ac8015cde48305aeb82724039)

RESTRICT AUTOMERGE Use consistent calling uid and package in navigateUpTo

Originally, if the caller of navigateUpTo is alive, even the calling
uid is set to the caller who launched the existing destination activity,
the uid from caller process has higher priority to replace the given
calling uid. So this change doesn't modify the existing behavior if
the caller process is valid. Besides, the case of delivering new intent
uses the source record as calling identity too, so the case of starting
new activity should be consistent.

Also forbid attaching null application thread to avoid unexpected state
in process record.

Bug: 144285917
Test: bit FrameworksServicesTests:com.android.server.am.ActivityStackTests
Change-Id: I60732f430256d37cb926d08d093581f051c4afed
(cherry picked from commit 0d7e27af30e39fbb6dcafedc854daa639074e5cc)

DO NOT MERGE - Kill apps outright for API contract violations

...rather than relying on in-app code to perform the shutdown.

Backport of security fix.

Bug: 128649910
Bug: 140108616
Test: manual
Test: atest OsHostTests#testForegroundServiceBadNotification
Change-Id: I94d9de50bb03c33666471e3dbd9c721e9278f7cb
Merged-In: I94d9de50bb03c33666471e3dbd9c721e9278f7cb
(cherry picked from commit 874c974f73839da761177a4e0a53b7f4a7d29288)