When wide color gamut rendering is requested, hwui will now
use an rgba16f scRGB-nl surface for rendering. This change
also fixes the way screenshots are handled in the platform
to behave properly with wide gamut rendering.
This change does not affect hardware layers. They also
need to use rgba16f scRGB-nl; this will be addressed in
another CL.
Bug: 29940137
Test: CtsUiRenderingTestCases, CtsGraphicsTestCases
Change-Id: I68fd96c451652136c566ec48fb0e97c2a7a257c5
We would like to reuse the animation parts of it in Android things.
This refactors the audio part into the _main and gets callbacks from
the BootAnimation class at interesting times. This will be the same
approach we take to integrate with it.
BUG: 37992717
Test: Built locally and pushed to a bullhead, works with sound.
Change-Id: I5eaca07c25eeb5edeab07d7ae7a29945e0e2cd37
When answering the question "how much space is free", use the same
logic for Settings UI and StorageManager.getAllocatableBytes(). That
is, the reported free space is usable bytes plus any cached data the
system is willing to delete automatically.
This does *not* include any reserved cache space, since we don't want
abusive apps to penalize other well-behaved apps that are storing
their data in cache locations. Callers freeing cached data need to
now explicitly request defiance of the reserved cache space. (Most
callers are already doing this by using FLAG_ALLOCATE_AGGRESSIVE.)
Rewrite the core logic of DeviceStorageMonitorService to understand
this new "reserved" cache space, and to be easier to understand. It
also now handles cached data on adopted storage volumes, which had
been ignored until now. Also fix bug where we had skipped "low"
broadcasts when the device skipped directly from/to "full" state.
Bug: 38008706
Test: cts-tradefed run commandAndExit cts-dev -m CtsJobSchedulerTestCases -t android.jobscheduler.cts.StorageConstraintTest
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.StorageHostTest
Change-Id: Icbdcf3b52775f7ada1ceaeff2f96094c8d8052f9
Instead of directly adding dependencies to full_classes_compiled_jar
and full_classes_jack, just use LOCAL_ADDITIONAL_DEPENDENCIES and
let the build system take care of where the dependencies are needed.
Test: builds
Change-Id: Ia3078fe0aa54b2d69821a9879cfe43414e1e9c4f
- Add separate 100ms interval polling for SurfaceFlinger. Otherwise,
it can be blocked with 1 sec polling and cause 1 sec of additional
delay frequently.
bug: 38450031
bug: 35253872
Test: many reboots and check time to finish boot animation, python packages/services/Car/tools/bootanalyze/bootanalyze.py -r -c packages/services/Car/tools/bootanalyze/config.yaml -n 100 -f -e 15 -w 30 -v
Change-Id: I353ca04183cbe59b82da99dc3fecfce63314cd2f
"--verify" will be used to verify if idmap corresponding to given fd is maded
from given target and overlay packages.
Test: building succeeded and tested on sailfish.
Bug: 37179531
Change-Id: Id19bdfd9c61670437f3e1a5c29762ce93586590f
Hid command, JNI layer:
- Removed dependency of the hid device on libandroid_runtime
and libutils. Using ALooper from libandroid to process callbacks from
/dev/uhid file descriptor.
- Switched to using "CREATE2" and "INPUT2" constructs in uhid driver
Hid command, Java layer:
- Removed delay workarounds, user now responsible for waiting for
onInputDeviceChanged notification prior to using the hid commands.
UiAutomation:
- Added a new executeShellCommandRw function that allows bidirectional
communication to shell command
platform.xml:
- Added uhid permissions to bluetooth stack for /dev/uhid access
- CTS test now consistently passes
Bug: 34052337
Test: CTS test case invoked with the following command:
run cts -t android.hardware.input.cts.tests.GamepadTestCase
-m CtsHardwareTestCases --skip-system-status-check
com.android.compatibility.common.tradefed.targetprep.NetworkConnectivityChecker
Change-Id: Ic916c513b7e652b1e25675f0f38f0f1f3a65d214
To work around race conditions in libbinder when
spawning new threads while being shut down.
Bug: 36066697
Test: screencap still works
Change-Id: I774d3dc2491bb578a12dede90cc7fcded976f13f
There is now an IBinder "token" that must be specified when setting
the whitelist duration for an Intent. To have the whitelist supplied,
the caller to send a PendingIntent must pass in the same token. The
PendingIntent and IntentSender classes now internally maintain this token
to pass in when their send() is called.
The big complexity for making this work is we now need to associate this
whitelist token correctly with the actual PendingIntent objects that
applications and other code is getting. To do this, we propagate the
token in the Notification object, and have a new API on Parcel that allows
us to make it available to PendingIntent when it is unmarshalled. And
this allows to deal with PendingIntents appearing in nested bundles, as
we can propagate that information from the original Parcel to the new
Parcel that Bundle keeps to delay unmarshalling.
Test: manual
Change-Id: Idda00490ccfe2be37e4ab21354b9ab7528a52750
In preparation for removing junit and android.test classes from
the Android API this change adds explicit dependencies on junit
and/or legacy-android-test to ensure that modules will compile
properly once it is removed.
Care was taken to ensure that any targets that depended,
directly or indirectly, on android-support-test did not also
depend on junit or hamcrest as they conflict with the versions
embedded within android-support-test.
Bug: 30188076
Test: make checkbuild
(cherry picked from commit 00229bc6cfd74c3221d02af6df07960a0f36af1a)
Change-Id: I7fea20f92a5a92885733bc6ecb83b7276a48fbc2
Merged-In: Ifc3ee3dc804074a3c572bf2600cfb1fe1b6fa749
In preparation for removing junit and android.test classes from
the Android API this change adds explicit dependencies on junit
and/or legacy-android-test to ensure that modules will compile
properly once it is removed.
Care was taken to ensure that any targets that depended,
directly or indirectly, on android-support-test did not also
depend on junit or hamcrest as they conflict with the versions
embedded within android-support-test.
Bug: 30188076
Test: make checkbuild
Change-Id: Ice80a29b420061f5d0af6eb46426455abf890e5e
Merged-In: Ifc3ee3dc804074a3c572bf2600cfb1fe1b6fa749
In preparation for removing junit and android.test classes from
the Android API this change adds explicit dependencies on junit
and/or legacy-android-test to ensure that modules will compile
properly once it is removed.
Care was taken to ensure that any targets that depended,
directly or indirectly, on android-support-test did not also
depend on junit or hamcrest as they conflict with the versions
embedded within android-support-test.
Bug: 30188076
Test: make checkbuild
Change-Id: Ifc3ee3dc804074a3c572bf2600cfb1fe1b6fa749
We've seen evidence of lab devices racing with other apps that are
using cache space immediately after tests wipe it clean, which can
cause test failures. To mitigate this, try our best to wait for the
device to go "idle" by watching for broadcast queues to fully drain.
Also improve javadocs along the way.
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.StorageHostTest
Bug: 37486230, 37566983, 37913442, 37914374
Change-Id: I4d430db443b6fa6d33a625fe07b90279b5d51c12
CompatibilityDisplay used for displaying 2D activities in Vr world. This
is confusing in more than one way. To clarify what it really means,
rename it to Vr2dDisplay.
Changes in this CL -
- /s/CompatibilityDisplay/Vr2dDisplay
- /s/Compatibility/Vr2d - in CompatibilityDisplay context.
Bug: 37851944
Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test
CtsServicesHostTestCases android.server.cts.ActivityManagerDisplayTests
passes on Marlin.
Change-Id: I0a442302fa9d0f48bbd0c01a7766b94369e04386
Signed-off-by: Karthik Ravi Shankar <karthikrs@google.com>
To prevent it from hanging up.
Bug: 37500397
Bug: 34085250
Test: DismissDialogsInstrumentation test
Change-Id: Ia69f6a5676666bc9286272b82f242d7b1d0ee286
To be able to control the Vr compatibility virtual display's is useful.
In this case, it will be useful to control and test the
CompatibilityDisplayProperties API in VrManager.
Bug: 37260266
Test: adb shell set-compatibility-display-properties 500 500 500
adb shell dumpsys display
>> mBaseDisplayInfo=DisplayInfo{"VR 2D Display", uniqueId
"virtual:android,1000,VR 2D Display,0", app 500 x 500, real 500
x 500, largest app 500 x 500, smallest app 500 x 500, mode 6,
defaultMode 6, modes [{id=6, width=500, height=500, fps=60.0}],
colorMode 0, supportedColorModes [0], hdrCapabilities null,
rotation 0, density 500 (500.0 x 500.0) dpi...
Change-Id: Ice5bc569f380154bf2d9e9f9b9387e801d678774
Signed-off-by: Karthik Ravi Shankar <karthikrs@google.com>
The purpose here is to provide support for selectively
enabling Runtime Resource Overlays (RROs) (specifically
those pertaining to a specific SKU, within a OEM's "single
build" covering multiple SKUs) at boot based on the value
of a pre-defined system property.
This mechanism is designed to be compatible with other,
recent changes to Runtime Resource Overlays - specifically:
- has no effect on 'isStatic'. Resource overlays must be
attributed as static in order to qualify for loading into
the system_server. The 'requiredSystemPropertyName/
requiredSystemPropertyValue' mechanism operates
independent of this and can be used on both static and
non static overlays. The effect of specifying a conditional
property on any overlay is that it will ONLY be enabled
in the event that the system reflects both the property
and the specified value (Note that in the ABSENCE of a
conditional property, overlays are assumed to be enabled).
- has no effect on OverlayManagerService (OMS) API. The
OMS provides the system with an interface through which
overlays can be enabled/disabled and even rearranged at
runtime. This provides the basis of support for various
user-level features (e.g. dynamic theme selection).
The 'requiredSystemPropertyName/requiredSystemPropertyValue'
mechanism operates independent of this -
with enablement being completely coupled to the available
system properties on the device and NOT subject to change
at runtime.
Note: as part of this change, original overlay tests have been
updated (fixed) and expanded to include tests to cover the
conditional property implementation.
Issue: http://b/35100249
Test: frameworks/base/core/tests/overlaytests/testrunner.py
Change-Id: I1990ce21a27a385db1e2f53294b69dd03988351e
(cherry picked from commit d5566c6c47faa6b9dda282741e25ac78c9487d58)
The purpose here is to provide support for selectively
enabling Runtime Resource Overlays (RROs) (specifically
those pertaining to a specific SKU, within a OEM's "single
build" covering multiple SKUs) at boot based on the value
of a pre-defined system property.
This mechanism is designed to be compatible with other,
recent changes to Runtime Resource Overlays - specifically:
- has no effect on 'isStatic'. Resource overlays must be
attributed as static in order to qualify for loading into
the system_server. The 'requiredSystemPropertyName/
requiredSystemPropertyValue' mechanism operates
independent of this and can be used on both static and
non static overlays. The effect of specifying a conditional
property on any overlay is that it will ONLY be enabled
in the event that the system reflects both the property
and the specified value (Note that in the ABSENCE of a
conditional property, overlays are assumed to be enabled).
- has no effect on OverlayManagerService (OMS) API. The
OMS provides the system with an interface through which
overlays can be enabled/disabled and even rearranged at
runtime. This provides the basis of support for various
user-level features (e.g. dynamic theme selection).
The 'requiredSystemPropertyName/requiredSystemPropertyValue'
mechanism operates independent of this -
with enablement being completely coupled to the available
system properties on the device and NOT subject to change
at runtime.
Note: as part of this change, original overlay tests have been
updated (fixed) and expanded to include tests to cover the
conditional property implementation.
Issue: http://b/35100249
Test: frameworks/base/core/tests/overlaytests/testrunner.py
Change-Id: I1990ce21a27a385db1e2f53294b69dd03988351e
bu is used by adb backup/restore, but since flags passed to these adb
commands are just forwarded to bu, we have no guarantee that the help
text for adb shows an up to date description of what bu can do. We
therefore add the help text to bu, such that it is easier to keep in
sync.
Test: adb shell bu help
Bug: 36170696
Change-Id: I8155d17b5c942ce19b981f4a157e7cc7810490ce
- In new shutdown flow, adb is guaranteed to be alive while system server
is alive.
- power manager can be killed before system server is killed.
- This leads into RemoteException for shutdown request to power manager.
- If shutdown is already on-going (=sys.powerctl set), the RemoteException
should be ignored.
bug: 37096155
Test: adb shell svc power reboot|shutdown and check output to adb
Change-Id: Ia90a900d55123bd7c1bf57c90c49d35332ebfdf5
The original flag was added in ag/1946677. As pointed out
in ag/2065837 we ought to stick to the syntax used for
other flags.
Test: adb backup -keyvalue -all
Change-Id: Ie2c7ee3d85740abadaa4119d23470cd9470bd981
