Age | Commit message (Collapse) | Author |
|
Cherry-picked from klp-modular-dev
Provide an abstract class for system services to extend from,
similar to the android.app.Service.
This will allow services to receive events in a uniform way,
and will allow services to be created and started in the
correct order regardless of whether or not a particular
service exists.
Similar to android.app.Service, services are meant to implement
Binder interfaces as inner classes. This prevents services from
having incestuous access to each other and makes them use the
public API.
Change-Id: Iaacfee8d5f080a28d7cc606761f4624673ed390f
|
|
Provide system bar window visibility (showing/hiding) to sysui,
information it did not have before.
Use this new info to disable shade interaction when bars are hiding.
Bug: 8682123
Change-Id: I4105b789866f847582af1c68a703240d773fa71e
|
|
This is the best and only way for apps to listen for
notifications: create a NotificationListenerService, wait
for the NoMan to bind to you (as a result of the user
checking a box somewhere in Settings and agreeing to a
scary dialog box), and you'll start receiving notification
posted and dismissed callbacks. Your service, while enabled,
will also be able to clear one or all notifications.
Use this power wisely.
This change moves StatusBarNotification out of
com.android.internal into android.service.notification.
[Internal customers, including System UI and early users of
the system-only listener binder API, will need to be
updated.]
Bug: 8199624
Change-Id: I1be46f823d4b3ddc901109ec1e085cd6deb740c2
|
|
First, do no harm.
Bug:7638210
Change-Id: I113b574a021d601b0c79d65a3b4b72eeb4c667ad
|
|
Two things going on here, status bar disabled flags need to be reset
on user switch. Also make status bar's internal disable-record lookup
multi-user aware.
Bug:7278793
Change-Id: I1d7088d956a065330736da4c09cc1874c528c133
|
|
Bug:7165607
Change-Id: If6f7a41c2516996612aef5e013dd0d2bd23f9084
|
|
IStatusBarService.collapseQuickSettings is gone;
collapseNotifications is now collapsePanels, which does what
collapse() used to do. Similarly,
IStatusBar.animateCollapseQuickSettings is now simply
IStatusBar.animateCollapse().
Bug: 7245229
Change-Id: Id157d2fdf34926d3c85ffa8b81c741a5359aede4
|
|
jb-mr1-dev
|
|
1. Added APIs for opening the quick settings to the StatusBarManagerService
and the local StatausBarManager. The new APIs are protected by the old
EXPAND_STATUS_BAR permission.
Renamed the expand* and collapse* non-public APIs that are expanding
the notifications to expandNotifications* collapseNotifications* to
better convey what they do given that this change adds
expandQuickSettings* and collapseQuickSettings*.
Added a global action to the accessibility layer to expand the quick
settings which is calling into the new status bar manager APIs.
bug:7030487
Change-Id: Ic7b46e1a132f1c0d71355f18e7c5a9a2424171c3
|
|
For apps that are only installed on secondary users, the SystemUI is
unable to see them by default. Added some methods to explicitly pass the
userId of the user the resources are requested for by the StatusBarIcon
Bug: 7214384
Also fix binding to remote views
Bug: 7192802
Change-Id: I5d6c5f624aa37fb231f3467f9764c8d99077a91d
|
|
Replaced all remaining places that used it with explicit user
specification.
While doing this, I ran into stuff that was creating PendingIntent
objects (that now need to specify the explicit user they are for),
which are also posting notifications... but have no way to specify
the user for the notification.
So the notification manager in the system process now also gets a
formal concept of a user associated with the notification, which
is passed in to all the necessary aidl calls. I also removed the
old deprecated aidl interface for posting/cancelling notifications,
since we now always need a user supplied.
There is more work that needs to be done here, though. For example
I think we need to be able to specify USER_ALL for a notification that
should be shown to all users (such as low storage or low battery).
Along with that, the PendingIntent creation needs to be tweaked to
be able to handle USER_CURRENT by evaluating the user at the point the
pending intent is sent.
That's for another change, however.
Change-Id: I468e14dce8def0e13e0870571e7c31ed32b6310c
|
|
You shouldn't do it, but there's no need to fault your
process.
Bug: 6396830
Change-Id: I47c20b9829e4e8bb98862f33c3c52be1b5987f37
|
|
The main change is a few new flags you can supply to
View.setSystemUiVisibility(). One is a new visibility mode,
SYSTEM_UI_FLAG_FULLSCREEN, which is basically the same as
the global FLAG_FULLSCREEN option for windows, but driven as
part of the system UI state.
There are also three new flags for telling the framework that you
would like to have your application's UI ignore screen
decorations -- SYSTEM_UI_FLAG_LAYOUT_NO_NAVIGATION for going
behind the navigation bar and SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN
for ignoring full screen decorations (that is the status bar).
In combination with this you can use SYSTEM_UI_FLAG_LAYOUT_STABLE
to have the framework report consistent insets to your application.
When using NO_NAVIGATION, when the user taps the screen we now
also automatically clear ONLY_CONTENT, so that we atomically show
both UI elements. This should make it easy for apps like video
players that want to move between fully full-screen and regular
modes.
The ActionBar has also been extended when in overlay mode so
that it will adjust the system window insets to also account
for its space, and allow it to be hidden using the new
SYSTEM_UI_FLAG_FULLSCREEN.
Change-Id: Ic8db1adec49a0f420bfe40c1d92eb21307856d0b
|
|
Also refactor recents code across Phone/Tablet
Change-Id: Id557c5cb0f7d9378f81c40b20511a5d98bf4078e
|
|
The PhoneWindowManager is now responsible for hiding and showing
the nav bar.
For hiding, it just moves it off the screen (easy way to get a
nice slide animation on and off). At the same time, we use a
new WM facility to put up a fake input window to capture all
touch events.
When a touch event is received, we force the system UI to clear
the navigation hiding bit so it will be shown again.
This removes a bunch of code from the system UI for hiding and
showing the nav bar. Also removes the code calling from userActivity()
to the system UI, which was bad. (Also no longer using userActivity()
fixes bugs around re-showing the nav bar due to key presses and
other wrong things.)
Change-Id: I8c3174873b5bcaa36a92322a51e8f7993e88e551
|
|
Touching StatusBar.disable() directly can make the cached value over
in StatusBarManagerService stale. Instead, dispatch DISABLE_BACK
through setSystemUiVisibility() on tablets; it's unused on phones.
Also DISABLE_NOTIFICATION_TICKER when showing secure lockscreen, and
watch for TIME_CHANGED in DateView.
Bug: 5255469
Bug: 5242677
Change-Id: I4efaf9799b2f229f49d7024da5dafceacd5e08bb
|
|
View.setSystemUiVisibility() now properly accepts a
bitfield, including:
* SYSTEM_UI_FLAG_LOW_PROFILE: "lights out mode"
(previously known, erroneously, as STATUS_BAR_HIDDEN)
* SYSTEM_UI_FLAG_HIDE_NAVIGATION: for when you need every
single pixel on a device that also has a navigation bar
These flags are painstakingly aggregated across the entire
view hierarchy and carefully delivered to the status bar
service, which in turn gently passes them along to the bar
implementation.
To really get access to the whole screen, you need to use
HIDE_NAVIGATION in conjunction with FLAG_FULLSCREEN and
FLAG_LAYOUT_IN_SCREEN. See development/samples/Overscan for
an example of how to do this.
Change-Id: I5fbfe009d9ceebbbf71db73f14a7008ea7c1d4da
|
|
1. Added content description to pretty much all animals
in the zoo including buttons in the navigation bar,
notifications and status icons for battery, signal,
data, etc.
2. Rectored to avoid ovelaying views since they block
touch exploratino. In general overlaying views
cause trouble for touch exploration and accessibility
in general.
3. Avoid sending accessibility events in case the user is
touching outside of the StatauBAr panels to avoid
confusion.
4. Added records to accessibility events in the places where
this would help the presentation. So the event comes from
a given "leaf" view and its predecessor is adding a record
to the event for itself to provide more cotext. It is up
to the accessiiblity service to choose how to present that.
bug:4686943
Change-Id: I1c1bd123d828fb10911bca92130e9a05c1f020b3
|
|
- wire up to long press on home
- remove unused recents activity
- remove duplicate recents resources in -large directories (using -sw600dp instead)
- fix issue with zoom/scale translation when recents was brought up
Change-Id: I45538ccaff49b46ac3659c4828f9e2b0cd075241
|
|
Change-Id: I9af0c08a9f1c1f68661efe051a66835e850b76f6
|
|
We now tell the system bar every time the top activity has changed for
it to re-evaluate its UI state.
Also fix issue #: 4607102 Low rider notifications. It turns out this
was due to the change in the dialog asset; the notification UI was relying
on this having a lot of padding to make it sit above the status bar.
Now we have an explicitly mechanism to set how much it overlaps (or doesn't)
the status bar.
Change-Id: Iab5ebd86e620ff4fc4cd77206e18af962ec2830e
|
|
Views requesting lights out mode will cause the navbar to
disappear (this is useful for viewing videos/photos/etc
using every pixel of the screen).
But there's a catch: any user activity at all will cause the
lights to come back on and the navbar to return.
Change-Id: I535ed3ba9ae7fab3282c402be256add765395b6f
|
|
Move all of the pieces into a new com.android.server.wm package.
Change-Id: I942b7bcfb84ee0f843f47d58e55ffc5a93c0da94
|
|
Bug: 3391067
Change-Id: I136087ca4f726d0068d5983d7d3686787ba60c55
|
|
fields.
Bug: 3363046
Change-Id: I50ba06ed9a4d2f5d0e0c807437aea9900f44fee9
|
|
to the status bar.
Bug: 3391067
Change-Id: I049531155bf7ee0b29874916c0b5b0a45b73c09e
|
|
lights out mode on its
own.
Bug: 3241144
Change-Id: Id09437a4f32f1d64daa7ae65e41c99897b5964d7
|
|
Change-Id: I4a0aa8789f537717f82df4efb6a35108e1ab1784
|
|
1. Views may setSystemUiVisibility() to recommend that
the system chrome (status bar or other UI) show or hide
itself. (This functionality was previously available only
via the FLAG_FULLSCREEN window flag for some SystemUI
implementations.)
2. Views may register a OnSystemUiVisibilityChangedListener
on a view, and find out when the system UI actually
appears or disappears, allowing apps to coordinate the
appearance of their own UI if desired.
Bug: 3241144
Change-Id: Ia1758d94099182d49a1e3688ea2738ae4995b829
|
|
to a shortcut IME from the system bar
Bug: 3212206
Bug: 3201828
- Added a shortcut IME button. This will be used for calling a shortcut IME (e.g. Voice input)
- Made the positions of IME buttons left aligned
- IME token is required to change IME because of the security reasons.
Change-Id: I48ba5e2509b3aa1bfd2394f9201427fa6b93c6d3
|
|
Change-Id: Ib89959d1ea13f1e6f56e6280f90532e6695c4a00
|
|
comes up.
Bug: 3108996
Change-Id: I92c2ff645dc64ca2610e3de814e0cfef6cde88c3
|
|
Bug: 3077030
- IME communicates with status bar directly.
Change-Id: Ic5b6b5b7a2b8ea62372dcc9b9c36d81b9f2db651
|
|
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
|
|
Change-Id: I42b7b433c86a71a5da5db67109f056a280077c9d
|
|
Remember, the system and main logs are
- Shared resources
- Primarily for recording problems
- To be used only for large grained events during normal operation
Bug: 3104855
Change-Id: I136fbd101917dcbc8ebc3f96f276426b48bde7b7
|
|
Windows with FLAG_NEEDS_MENU_KEY (or windowNeedsMenuKey=true
in their theme) will cause the system bar to show a menu
icon. (Note that the phone's status bar currently ignores
this, but phones tend to have hardware menu keys anyway.)
Additionally, all windows whose package's SDK version is
pre-Honeycomb will have FLAG_NEEDS_MENU_KEY set by default.
Bug: 3003728
Change-Id: I2d983763a726ea4f32cd1af9b0390e30478b11d1
|
|
It took a little bit of refactoring to move the authoritative state
about whether the lights are on or not into the StatusBarManagerService,
so that if the system ui process crashes, the bar comes up in the
right mode.
Change-Id: I95cfaf8f78ca4443ded5262272ea755d44dc5d17
|
|
running in the system ui process.
Lights out mode itself isn't implemented.
Change-Id: Ieeef0eb9ae5be23000f770e74e8ee66472f4c673
|
|
Line-item veto is there, but allows you to cancel some
notifications you probably shouldn't be canceling. (Should
hide the "X" in those cases.)
No preference given to "sticky" notifications, because
there's no such thing yet.
Notifications are now limited to 4 visible icons, per spec.
The implementation is a total hack for now.
Change-Id: Ibdf433ae94189117f983c510fe5e0cff0bf5c44c
|
|
Implement notification manager handling of bad notifications, to
call a new activity manager to have the owner's process crashed
(if there is one).
Change-Id: Ib15e8d0c598756f3b39c99cc2045c18e054daf6b
|
|
Change-Id: Ie495a41dac03e1fe5ddccefcbd2a0673090a6db1
|
|
This lets it turn off the LED. However, it seems like somebody broke
the notification LEDs. GRRR.
Change-Id: I3f7066c2b2e1673dc0144a34cf59946351a647be
|
|
Then, now that StatusBarManagerService is the only thing in that package,
move it up to the regular services package. (I've been waiting for 4 years
to delete that package!)
Change-Id: If5faf44641319fd19e486d1f4e5bc1c6dfcff3ad
|