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 00229bc6cf)
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: 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 d5566c6c47)
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
- init will set sys.powerctl property and run bootanim.
- Use /oem/media/shutdownanimation.zip or
/system/media/shutdownanimation.zip for animation file.
If none of them exist, android animation will be used.
- Disable audio playing for shutdown animation.
- Disable TimeCheckThread for shutdown animation. It
accesses /data partition and can block umount.
bug: 36526187
Test: many reboots
Change-Id: If02c73cda2015317d88d056cd45201208da49946
It's extremely difficult to test storage related logic on devices
that don't have physical SD card slots. So to support better
debugging and testing, add a new "virtual disk" feature which mounts
a 512MB file through loop device.
Also move ParcelFileDescriptor.open() over to using Os.open() so
that it gets StrictMode treatment.
Bug: 34903607
Test: builds, boots, virtual disk works
Change-Id: I072a3a412cfcc8a2a3472919b7273a1ed794fd98
For adding CTS tests for packages having key-value backup agents, we add
support for key-value backups to the adb backup/restore command.
Previously, packages not supporting fullbackup would just be skipped on
this command. Now, by adding the -keyvalue flag to the adb backup command,
packages supporting key-value will also be added to the resulting
tarball. Similarly, if the tarball being supplied to adb restore
contains data from key-value packages, it will be restored.
This will later be utilized for writing CTS tests for such packages.
Test: adb backup -includekeyvalue -all && adb restore backup.ab
Change-Id: I7b4ccfb7072d01d29a888952145d7cce90a4f59e
Applications with the android:isolatedSplits="true" attribute in
their AndroidManifest.xml would have their Split APKs loaded in
isolation of each other, based on a set of dependencies.
Configuration Splits generated for a Feature split would not be properly
loaded before, so this change, along with a tools change, fixes this
issue and completes support for isolatedSplits.
Bug: 30999713
Test: CTS test coming (depends on some tool changes)
Change-Id: Ia4e7b0e69168a9d6637867558e306f7031720fb3
Static RRO package is designed to support resource overlay for system
server and they shouldn't be disabled or changed by a user.
The design details are in go/treble-static-rro.
Selection method for static RROs will be applied later when its design
is determined.
Test: building succeeded and tested on sailfish.
Bug: 35742444
Change-Id: I8cbf2fd37a73a24bf6ad291e2c5cf75a0fc757fc
This CL moves rotation tracking from WindowManagerService to
DisplayContent. This way displays can be rotated independently and
rotation of the main display won't affect rotation of secondary
ones.
Bug: 34242678
Test: android.server.cts.ActivityManagerDisplayTests
Test: testRotationNotAffectingSecondaryScreen
Change-Id: Ic46aaa523482b31ff5ec77f0c2908ceda1156fc0
Hand over ownership of overlays to OverlayManagerService.
Changes to a package's overlays are propagated using the activity life
cycle. Affected activities will be recreated as needed. This provides a
well-defined point to modify an application's assets while the
application is paused.
Consolidate how overlays targeting the system and overlays targeting
regular applications are handled. Previously, system overlays were
handled as a special case. Now, everything is handled identically. As a
side effect, the call to idmap --scan during Zygote boot has become
obsolete and is removed.
Information on what overlays to use is recorded in
ApplicationInfo.resourceDirs. The PackageManagerService is responsible
for the creation of ApplicationInfo objects. The OverlayManagerService
is responsible for informing the PackageManagerService in advance about
what resourceDirs to use.
When launching an application, the ApplicationInfo is already populated
with up-to-date information about overlays.
When enabling or disabling an overlay for a running application, the
OverlayManagerService first notifies the PackageManagerService about the
updated resourceDirs. It then tells the ActivityManagerService to push
the new ApplicationInfo object to the application's ActivityThread.
Finally the application requests its ResourcesManager to create new
ResourcesImpl objects based on the updated paths.
Change-Id: Ib8afa05ccab4e2db558f89ce4423983c086bb61a
Co-authored-by: Martin Wallgren <martin.wallgren@sonymobile.com>
Signed-off-by: Zoran Jovanovic <zoran.jovanovic@sonymobile.com>
Bug: 31052947
Test: run tests from 'OMS: tests for OverlayManagerService'
Hand over ownership of overlays to OverlayManagerService.
Changes to a package's overlays are propagated using the activity life
cycle. Affected activities will be recreated as needed. This provides a
well-defined point to modify an application's assets while the
application is paused.
Consolidate how overlays targeting the system and overlays targeting
regular applications are handled. Previously, system overlays were
handled as a special case. Now, everything is handled identically. As a
side effect, the call to idmap --scan during Zygote boot has become
obsolete and is removed.
Information on what overlays to use is recorded in
ApplicationInfo.resourceDirs. The PackageManagerService is responsible
for the creation of ApplicationInfo objects. The OverlayManagerService
is responsible for informing the PackageManagerService in advance about
what resourceDirs to use.
When launching an application, the ApplicationInfo is already populated
with up-to-date information about overlays.
When enabling or disabling an overlay for a running application, the
OverlayManagerService first notifies the PackageManagerService about the
updated resourceDirs. It then tells the ActivityManagerService to push
the new ApplicationInfo object to the application's ActivityThread.
Finally the application requests its ResourcesManager to create new
ResourcesImpl objects based on the updated paths.
Co-authored-by: Martin Wallgren <martin.wallgren@sonymobile.com>
Signed-off-by: Zoran Jovanovic <zoran.jovanovic@sonymobile.com>
Bug: 31052947
Test: run tests from 'OMS: tests for OverlayManagerService'
Change-Id: Idc96dae6fc075d5373aa055bbf50e919136d7353
