SystemUIService is hard-coded to dump at CRITICAL priority and so can't
dump very much (and, most importantly, can't handle dumping our length
log buffers). So instead we create a new service,
SystemUIAuxiliaryDumpService, which will dump alongside all other
services in the NORMAL section. Its dump method calls straight into the
DumpManager.
Test: atest, manual
Change-Id: If76f206081a1663e23fc14076b50bef7396e517f
Introduces DumpManager, a unified dumping system that supports dumping
at different priority levels.
Currently, when a bug report gets taken, SystemUI is only dumped during
the CRITICAL section. This has its advantages (we get to go first!) but
also imposes a strict limit on how much we can dump. To get around this
restriction, we need to *also* dump SystemUI during the NORMAL section,
which has much more forgiving constraints.
This CL simply creates the mechanism for systemUI to dump at different
priority levels, but doesn't actually cause us to participate in the
NORMAL section (yet, see later CLs).
It introduces the DumpManager, unified replacement for DumpController &
various logic in SystemUIService and Dependency.java. See kdoc in
DumpManager for usage notes.
Migration of current users of DumpController coming in a later CL.
Test: atest, manual
Change-Id: If4f41ed496c0c64024a83aad812b77f60fe27555
This was polluting the output of selective dump from
adb shell dumpsys activity service com.android.systemui/.SystemUIService dependency DumpController <tag>
Test: manual
Change-Id: Ifcfb97e3edf2005e16a1433862fe9094927c0761
Test: presubmit setup on source branch
Bug: 130289146 Create a Gradle build for SystemUI
Bug: 136279712 Daggerize FalsingManager
Bug: 137324767 "Unable to instantiate service com.android.systemui.doze.DozeService" exception breaks launcher tests
Bug: 137563419 Remove Bouncer reveal delay from bypass flow
Bug: 138787339 Allow Services and Activities to be injected into directly.
Bug: 139128921 [AS 3.5 RC2, SDK API 29 rev 2] Overload resolution ambiguity: while removing element from HashMap
Bug: 64712476 Import translations for dev branches
Change-Id: Ib7fd4706c070907fd556c3532957f3b1b046de6d
Dependency is no longer a subclass of SystemUI. It gets initialized
directly as part of the application, just like the rest of Dagger.
It was an awkward implementation of SystemUI anyways.
Bug: 137324767
Change-Id: Icf49e9262e8c0710210a8bc0231c4d16396ffdf3
Test: atest SystemUITests
In addition to changing imports, this required some changes to use java
7, since that's what the shared lib needs to be for launcher.
See bug for more details on this project.
Test: "atest com.android.systemui.shared.plugins"
build succeeds and all tests pass
Bug: 115877296
Change-Id: Ib79ede0a61664df0ba1a194632a345d2229777fc
Also adds some additional debugging:
`adb shell dumpsys activity service SystemUI` will now dump
the plugin map. This will help us discover leaks that happen
to interact with plugins, or leaks in the plugins themselves.
(Note that plugins only work on debuggable builds.)
Bug: 72138063
Test: adb shell dumpsys activity service SystemUI
Change-Id: I328aeb9a0940404760e9121ef26a0518371b8319
When a device gets stuck in a crash loop, it's pretty much unusable
and impossible for users to recover from.
To help rescue devices from this state, this change introduces a new
feature that watches for runtime restart loops and persistent app
crash loops, and escalates through a series of increasingly
aggressive rescue operations. Currently these rescue levels walk
through clearing any experiments in SettingsProvider before finally
rebooting and prompting the user to wipe data.
Crash loops are detected based on a number of events in a specific
window of time. App stats can be stored in memory, but boot stats
need to be stored in system properties to be more robust.
Start up RecoveryService much earlier during the boot so we can
reboot into recovery when needed.
Add properties tha push system_server or SystemUI into a crash loops
for testing purposes.
Test: builds, boots, forced crashing walks through modes
Bug: 24872457, 30951331
Change-Id: I6cdd37682973fe18de0f08521e88f70ee7d7728b
The old logic with waiting for the Keyguard to be drawn assumed that
it is in an own window, and just checked for the visibility. This is
no longer possible as the Keyguard is in the status bar, and the status
bar might have been drawn without the Keyguard. So we have to wait
explicitely until Keyguard told PhoneWindowManager that it has now been
drawn and we can turn on the screen.
In addition, the starting logic of SystemUI is moved into
SystemUIApplication such the we can make sure that the status bar
already exists when the callbacks from PhoneWindowManager reach
KeyguardService. This simplifies the logic a lot.
Bug: 13635952
Change-Id: Ifd6ba795647edcf3501641e39052e4d04bc826fb
Hoist the usb storage notification listener to a top-level
system ui service, not dependent on a status bar implementation.
Change-Id: Ic9e7fba1e5bfd758d72226f6d796c2f04f6b17e6
Remove remaining references to recents package from status bar.
Introduce in-process "components" to the existing SystemUI base class
to make component boundaries explicit, and implement Recents as the
first component.
Change-Id: Ieefd386379a1f46806b31f68a4cacd76c093aea4
If a service component is defined in a new secure setting,
SystemUI will attempt to use that service as the status bar
provider.
Falls back to the existing in-process implementation configured
in the product config if the setting is missing or invalid.
Nothing changes yet from a permission point of view. Alternative
system bar implementations still require the status bar permission.
Also nothing changes from an api point of view. Alternative
system bar implementations use the existing IStatusBar interface.
This simply enables testing alternative system bar implementations
installed from other trusted, platform-signed packages.
Known caveat: the setting is stored per user, multi-user changes
will be handled in a future CL.
Change-Id: I0413df185f7e75f77ad2ae1bc3689306d5e6e0fb
The system and some processes such as the keyguard and system UI
run across users. Hence, the local accessibility manager should call
into the backing system service with the id of the current user.
For all other processes the local manager uses the current user id.
There was a method that is to be called before the local accessibility
manager has been accessed to initialize it to work across users.
This had to be done for keyguard and system UI.
This change removed the workaround and now the local accessibility
manager determines under the hood which user id to use while calling
into the system. If the local manager is in the system process or
its process has permissions to work across uses, the manager uses
UserHandle.USER_CURRENT, otherwise it uses the user if its process.
Change-Id: I3e97fe98805adca01c1a0127a276828e90926f95
1. This change converts the accessibility manager service to
maintain a state per user. When the user changes the services
for the user that is going away are disconnected, the local
accessibility managers in the processes for this user are
disabled, the state is swapped with the new user's one, and
the new user state is refreshed.
This change updates all calls into the system to use their
user specific versions when applicable. For example, regisetring
content observers, package monitors, calls into other system
services, etc.
There are some components that are shared across users such
as UI created by the system process and the SystemUI package.
Such components are managed as a global state shared across
all users and are updated accordingly on a user switch. Since
the SystemUI is running in a normal app process this change
adds hidden APIs on the local window manager to allow the
SystemUI to notify the accessibility layer that it will run
accross users.
Calls to AccessibiltyManager's isEnabled(), isTouchExplorationEnabled()
and sendAccessibilityEvent return false or a are a nop for a
background user sice he should not send accessibility events,
and should not perform touch exploration.
Update the internal accessibility tests due to changes in the
AccessibilityManager.
This change also fixes several issues that were encountered
such as calling out the accessibility manager service with a
lock held.
Removed some incorrect debugging code from the TouchExplorer
that was leading to a system crash.
bug:6967373
Change-Id: I2cf32ffdee1d827a8197ae4ce717dc0ff798b259
Split WindowManagerImpl into two parts, the WindowManager
interface implementation remains where it is but the global
communications with the window manager are now handled by
the WindowManagerGlobal class. This change greatly simplifies
the challenge of having separate WindowManager instances
for each Context.
Removed WindowManagerImpl.getDefault(). This represents the
bulk of this change. Most of the usages of this method were
either to perform global functions (now handled by WindowManagerGlobal)
or to obtain the default display (now handled by DisplayManager).
Explicitly associate each new window with a display and make
the Display object available to the View hierarchy.
Add stubs for some new display manager API features.
Start to split apart the concepts of display id and layer stack.
since they operate at different layers of abstraction.
While it's true that each logical display uniquely corresponds to a
surface flinger layer stack, it is not necessarily the case that
they must use the same ids. Added Display.getLayerStack()
and started using it in places where it was relatively easy to do.
Change-Id: I29ed909114dec86807c4d3a5059c3fa0358bea61
Introduce IRingtonePlayer, which handles playback for both Ringtone
objects and Notifications. SystemUI now hosts this player, which it
registers with AudioService. It also keeps MediaPlayer instances
warm, and cleans them up after stop() or Binder death.
Move both Ringtone and NotificationManagerService to play back audio
through this new interface.
Bug: 6376128, 6350773
Change-Id: I1dcb86d16ee3c4f07cdb2248d33dcff4ead3609a
The status bar and navigation bar are two completely separate
elements, with their own semantics. The system bar now classifies
itself as a navigation bar, since that is really how it behaves.
This required rewriting the HDMI resizing code, so that it is
all done by PhoneWindowManager since that is what is responsible
for the size of the navigation bar (and thus now system bar). This
actually gets rid of a fair amount of code, and means we can also
do the same thing for a pure navigation bar.
Likewise the system bar now has the navigation bar ability to be
hidden when requested by system UI flags. To get the behavior
we want on Xoom, we only allow the nav bar to be hidden when it
will help provide a better aspect ratio for showing widescreen
videos.
Finally the nav/system bar now animates when hidden and shown.
Change-Id: Ie927154b68376a0b61802f99171ff56b8da92e7a
The PhoneWindowManager is now responsible for determing this,
since it needs to do this before we can generate the configuration
since we need to take into account the system bar size we will use.
Also the Display should now report the screen height without
including the system bar.
Change-Id: I82dfcc5e327e4d13d82c373c6c870f557a99b757
There is now one SystemUIService, which starts the status bar service.
Pretty soon there will be other things running in here too. This way
we don't need to have each of them started by something individually.
This also moves the choice between tablet and phone status bar into
SystemUI.apk, which seems like a much better place for it.
Change-Id: Ib69ef2f43d648764f8dbb52008f5d036a1ee07d9
