This new timeout will only apply when the device is docked, while still honoring any maximum timeouts set by DevicePolicyManager or WM.
Test: atest PowerManagerServiceTest
Test: locally on device, modifying the setting manually via adb
Bug: 213908097
Change-Id: I3d992154723fa8871f7c1c24607b16a35c42fb87
BufferStateLayer is the now the default interface to SurfaceFlinger
and BufferQueueLayer code path is obsolete and non-functional.
Test: presubmit
Bug: 217973491
Change-Id: I0d083230f3a27d4b0380a1d958fdc5c1b6c3aa51
This reverts commit c51683b7e7.
Reason for revert: API should not be expose, errorprone is being updated
Change-Id: I633ac76aa03982aa9cb03b1cc9f3d92ced94db4d
configurable.
The content of the half watchdog is now more consistent with watchdogs
to make it more actionable (watchdog subject, memory psi, cpu data).
The half watchdog is also published to dropbox in a similar way to the
watchdog. We also use a thread to publish to dropbox to make sure that
we do not block the watchdog handler code.
For the half watchdog, we know wait for 5s to get the cpu data (similar to
the watchdog) which delays the next run. That's only 10% of the default
timeout though so that's not a big difference.
For the configurable watchdog timeout, we delay fetching the value to
be able to start the watchdog as early as possible when system server
starts to detect blocked threads that might happen early. As well, even
if fetching settings is broken, the watchdog will still be running with
the default timeout values.
Test: tested that the half watchdog is added to dropbox
~/master$ adb shell dumpsys dropbox | grep watchdog
2022-01-25 23:22:19 system_server_pre_watchdog (compressed text, 21612 bytes)
2022-01-25 23:22:56 system_server_watchdog (compressed text, 21386 bytes)
2022-01-25 23:29:09 system_server_pre_watchdog (compressed text, 21621 bytes)
The watchdogs and half wathdogs were generated by adding a message with
a long sleep on the ui thread
Runnable runnable = new Runnable() {
@Override
public void run() {
SystemClock.sleep(40_000); // 40s
}
};
Message msg = Message.obtain(UiThread.getHandler(), runnable);
msg.setAsynchronous(true);
UiThread.getHandler().sendMessage(msg);
Bug: 209932320
Change-Id: I1bca723d1d7bee98dc7e1aade73a2e4384d6f035
Bluetooth is going mainline and can no longer use hidden api. We tried
to use the public alternative as our user is the same returned by
contentResolver.getUserId() but errorprone is not happy with it
Bug: 216769091
Test: Build bluetooth as apex mainline module
Change-Id: I195d545cc359d765e261c169032dfad46c916d75
CTS-Coverage-Bug: 217352944
The actual page is in GMSCore, which is not fully ready. I tested with
Nearby Share sharing page for indication.
Test: https://photos.app.goo.gl/E1T9hKtuci12SwuY7
Bug: 203579197
Change-Id: Idbbc4e6d5ca180a6d225b9410057473531bc2b0c
* changes:
Add API to configure LPS maintenance mode behavior
Add TestApi to force Low Power Standby to be active
Add TestApi wakelock flag to have system acquire wakelock
Allowlist active voice interaction session from Low Power Standby
Introduce Low Power Standby API and wakelock restrictions
Bluetooth is going mainline and need to have access to constant defined
in both settings.secure and settings.Global
Test: build
Bug: 211851706
Tag: #refactor
Change-Id: Id47da2e5606d29ccd2924d9105e8322a1b697ee1
Allow Low Power Standby to be active during doze maintenance modes.
Bug: 190822356
Test: atest LowPowerStandbyControllerTest
Change-Id: I6db6e1a37f48d63d618245f308ea1053c45fb64b
In Low Power Standby, additional restrictions are placed on apps that
are in a process state of FOREGROUND_SERVICE or less important
during standby (while the device is non-interactive):
- Wakelocks are disabled
- Network access is blocked
During doze maintenance windows the restrictions are lifted temporarily.
This change introduces the APIs for Low Power Standby, as well as
the wakelock restrictions.
This feature is targeting TVs. To prevent Low Power Standby from being
enabled on other devices, the feature is guarded by the config flag
config_lowPowerStandbySupported.
Bug: 190822356
Test: atest LowPowerStandbyControllerTest PowerManagerServiceTest
Ignore-AOSP-First: New permission only added internally for now.
Change-Id: Ia40f8a0fc4b366860af58ad76c988f93a5d41936
Client apps need the ACCESS_AMBIENT_CONTEXT_EVENT permission to use the service. The permission protection level is internal|role.
API overview: http://go/ambient-framework-api
PRD: http://go/ambient-attribution-prd
Design doc: http://go/ambient-service-api
Test: CTS test
Bug: 192476579
Change-Id: I9daede83af34f215c278cb0530238faba1be5c70
Ignore-AOSP-First: to prevent new feature leak.
In order for users to toggle complications on/off in Settings, we need
to categorize complications by type and store user preferences in
Settings.
Bug: 214038424
Bug: 214039192
Bug: 214038263
Test: make -j64 RunSettingsLibRoboTests ROBOTEST_FILTER="com.android.settingslib.dream.DreamBackendTest"
Change-Id: I2db4f2f9c1e08c6cfac3687fa3809662f30a3561
accesses. This is needed for aligning the location indicator to the
recent location accesses page in location settings.
Bug: 191503437
Test: manual
Change-Id: I9d2f473a75e3bfdfef59e675d2f6849e66cbbd94
This CL expands the existing UiModeManager APIs to allow users activate
dark mode at their configured bedtime schedule on supported devices,
i.e. devices with Digital Wellbeing preinstalled.
The CL added granular types for NIGHT_MODE_CUSTOM. There are two types
1. MODE_NIGHT_CUSTOM_TYPE_SCHEDULE
This is the type for a schedule set up by users via the Settings
app.
2. MODE_NIGHT_CUSTOM_TYPE_BEDTIME
This is the type for a bedtime schedule set up by users via the
Digital Wellbeing bedtime settings. Unlike
MODE_NIGHT_CUSTOM_TYPE_SCHEDULE, Android framework doesn't have
any information of the bedtime schedule. The activation of dark
theme lives inside Digital Wellbeing
Test: unit tests: atest FrameworksUiServicesTests:UiModeManagerServiceTest
CTS: atest CtsAppTestCases:UiModeManagerTest
Manual testing via a system app integration
Bug: 210975231
Change-Id: I3b16e649a048f8a485b9e9d6464d4f251839320d