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
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
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
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
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
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
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
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
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
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
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
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
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
