Adds TvInputManager methods to notify apps with protected broadcasts
for:
1. Disabling browsable state of preview and watch next programs.
2. Adding preview programs to watch next programs.
Test: build and verify manually to check if notifications are
broadcasted.
Bug: 35881266
Change-Id: I20fd5b63f42b2c74277315bbbd251b71c649e5c1
This CL cleans up APIs around font variation settings.
- Remove FontConfig and FontManager public API.
- Remove FontManagerService from system service.
- Extract inner class FontConfig.Axis as top-level class FontVariationAxis.
This is used by Typeface.Builder public API to create new Typeface.
- Introduce and expose FontVariationAxis utility functions from/to string.
- Throws if the invalid font variation settings is passed.
Test: android.text.cts.FontVariationAxisTest passes
Test: android.graphics.cts.TypefaceTest passes
Test: android.graphics.cts.PaintTest passes
Change-Id: I9ccafe7a53935960566243e2856e166878ca59ae
Creates a new UI Context for UI based operations.
This UI Context is wired up the same way a normal app
Context would be, and is subject to change when overlays
are enabled/disabled.
For this reason, only UI should be using this new Context.
All other operations should be using the original system Context
so that changing themes don't impact the regular operations of
system_server.
Also added some sanity checks at key places where we show UI
(ShutdownThread, BaseErrorDialog).
Bug: 36059431
Test: $ adb shell am crash com.android.settings
Test: Observe crash and power off dialogs are blue with PixelTheme
Change-Id: I87227ee2e0be1e72dcde8f482b37725cb687260b
1. Listen to calling package binder death stopping the scanning on that.
2. Don't restart scanning when a request with the same values was made.
Bug: 30932767
Test: 1.:
- Using a test app start scanning and kill the app.
- In debug mode ensure that DeviceDiscoveryService#stopScan gets triggered
2.:
- Start scanning and rotate the device while device chooser is visible
- Ensure no visible loss of state is happening
Change-Id: If126a2c963da90172a956fbd88e6b3dcd7ac8b01
- Move default global actions ui to sysui
- Add fallback legacy interface in case sysui breaks
- Switch to fallback if sysui dies or isn't responding
Test: Long-press power
Change-Id: I943522611de5dbbee61e66c67cf3a56379091e97
Otherwise, StartHidlServices waits for more than a second
while holding a lock, delaying window manager.
Test: boots
Test: SystemServerTiming_StartWindowManagerService does not regress
Logcat shows:
SystemServerTimingAsync: StartSensorService took to complete: 55ms
SystemServerTiming: StartWindowManagerService took to complete: 81ms
SystemServerTiming: StartHidlServices took to complete: 1ms
Test: lshal shows android.frameworks.sensorservice@1.0::ISensorManager
Bug: 36389997
Change-Id: Iab5cf0ad7059cf9736cc7db0567dff51cc427b58
The real dexopt maintainance job is
com.android.server.pm.BackgroundDexOptService, and not
com.android.server.BackgroundDexOptJobService
Partial revert of commit 096d304ae3d85c1bfcda1a1d9cd4eb13d0815500.
Test: manual inspection
Bug: 36140426
Change-Id: I983ac91117f107282095fa7eefdbce08e0dcfce3
Bug: 30932767
Test: Add just the feature gating first, ensure Context#getSystemSetrvice now
returns null.
Add feature in the configuration files, ensure companion device feature works again.
Change-Id: I4ad2d52f7877eae0e951f43ddbb23881d5de8d8b
1. Ensure clicking on a focused view brings up autofill if needed
2. Notify the autofill manager in a couple of cases we missed
3. Renamed the AutofillManager app facing APIs to better reflect what
they do and added a API for the app to cancel the autofill interaction
4. Fix view structure dispatch where the ordering of children for autofill
was mixed with ordering of direct view children - the autofill children
may be indirect as views can be marked not important for autofill
5. Show scrollbars only if there are more fill options than want is shown
6. Show only three fill options and the rest can be accessed with a scroll
7. Remove the list divider to allow fill items to control all fill window content
8. Renamed the autofill manager internal service classes to xxAutofillxx
9. Fixed a comment that was not addressed in a previous CL
10. Showing max three fill options - rest needs a scroll
11. Make sure fill UI shown when filter with no matches is changed
to filter with some matches
12. Make sure the fill window has a shadow
Test: Autofill CTS tests pass and manual
bug:36038929
bug:36040101
bug:36149166
bug:36034681
bug:36126001
bug:36035654
Change-Id: Ic8726146fc3c0a19d3e536becdd63fb65622136e
Adapts all notifications used by system services to use channels.
Channels are initialized by SystemServer after the NotificationService
has started.
Test: runtest systemui-notification
Change-Id: I25c45293b786adb57787aeab4c2613c9d7c89dab
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
ro.kernel.qemu based check to determine whether Bluetooth should be
started or not was an old hack used when "features" was not available to
determine hardware availability. This was later fixed with the
hasSystemFeature check. However, the old check was not removed.
The presence of the old check causes Bluetooth to not start on Android
Things devices which have ro.kernel.qemu set for graphics usage. It's
also preferable to depend on the system API rather than on build
configs. Related CLs modify the emulator builds to correct the config in
builds.
Bug: 35361545
Change-Id: I219ce5e14709c76dcba43af4693093e985269d43
Test: Verified by launching bluetooth on local devices after removing
the old check. Also verified by booting up the emulator and verifying
that Bluetooth Services do not start.
We now turn on lazy preloading (see companion change 73c7df1bda76a0)
and explicitly preload zygote resources.
To provide the most benefit :
- We start the preload in the system_server, which means the system_server
starts quicker since it has one less preload to wait for. Morever, the
64 bit zygote also starts quicker because it has one less high
priority process to contend with for CPU and I/O.
- We start the preload after the core system services start up, since we
know no 32 bit zygote processes will be requested before that point.
- We start the preload ~1s before the webview factory preparation, to
ensure that it completes before the 32 bit relro process is forked
from the zygote. In the event that it takes too long, the webview
RELRO process will block, but it will do so without holding any locks.
I have not observed this happening in > 200 runs on marlin / sailfish
devices.
This change saves about 500ms in boot times, and sometimes even more.
AFTER:
successive-online : 16970.0,16668.0,16391.0,16498.0,17601.0,16736.0,16609.0,16820.0,16310.0,17557.0,
successive-online_avg : 16816.0
successive-boot : 28750.0,29520.0,29372.0,28424.0,30683.0,28523.0,29766.0,29779.0,29304.0,31607.0,
successive-boot_avg : 29572.8
BEFORE:
successive-online : 16678.0,18105.0,17197.0,16744.0,17453.0,16946.0,18068.0,16719.0,17453.0,16942.0,
successive-online_avg : 17230.5
successive-boot : 30855.0,32069.0,31223.0,30918.0,30284.0,29750.0,31036.0,30778.0,30310.0,30908.0,
successive-boot_avg : 30813.1
Note that successive-online is a little faster, as expected since we do
less work in the 32 bit zygote.
Test: manual, timings from tradefed.
Bug: 34810190
Change-Id: I90207a2706afda163b8134ff2af31f6917f3841b
This introduces an API for apps that support companion devices to provide a
more streamlined flow for pairing and setting up the device
Bug: 30932767
Test: Using a toy app, invoke the newly introduced API (CompanionDeviceManager),
and go through the flow. Ensure filtering works, and device is returned to
the calling app. Ensure the calling app can pair to the selected device.
Change-Id: I0aeb653afd65e4adead13ea9c7248ec20971b04a
