| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
When the user taps on an intruder alert (the priority
notification in immersive mode), the .contentIntent in the
Notification object will be sent, just as we handle tapping
on a normal Notification in the windowshade.
Change-Id: Ib6991837b0b2122fe138cddacf347fdbc426b99d
|
|
|
|
|
|
|
|
|
| |
New actions:
- Toggle activity's immersive mode
- Post a priority notification with fullScreenIntent
that launches an alert-like activity
Change-Id: Ie38372209985577b6db856924c19914c000e1cec
|
|
|
|
| |
Change-Id: Ia5884ef46a5b0fa2d608c7924b3eb12293a1da8b
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On an inflation error, the StatusBarService cleans up, removes / doesn't add
the views, and calls into the StatusBarManagerService, which tells the
NotificationManagerService to remove the notification.
That then calls all the way back into the StatusBarService, but I think being
extra careful is okay. Throughout the status bar, it's all keyed off of the
IBinder key, so if the app comes in with a good notification while we're
cleaning up, we won't lose the new notification or anything like that.
Change-Id: Iea78a637495a8b67810c214b951d5ddb93becacb
|
|
|
|
|
|
| |
notification views.
Change-Id: I839d7771ab42a5d508ce7d15385f6ac6a4e3be83
|
|
|
|
|
|
| |
The test just wasn't testing that.
Change-Id: If1af2a7258d2a3764f845d9862a0a0ff62b1d7ed
|
|
|
|
| |
Change-Id: I87c5fe68ad8016596068ba7889f3b6d36da3386b
|
|
|
|
| |
Change-Id: I924763a2d42ca1967719f3eb72c57d1cbb912dd7
|
|
|
|
| |
Change-Id: I58ad95c59b2c46d3f25349e137d5624aefc6c6cd
|
|\
| |
| |
| | |
Change-Id: I8333e295ba6b6ed8e7658ecf3fbf1ebea3537aeb
|
| |
| |
| |
| |
| |
| | |
Context variables
Change-Id: If5139a1526101292e5da557bfad3f4db80fb64a8
|
|\ \
| |/
| |
| | |
Change-Id: I139c349b80b2cecfbdc30bd697cba099740293d9
|
| |
| |
| |
| |
| |
| | |
The test cases for turning on the RGB LED with persistent light was corrected.
The color for blinking was updated to blue. And finally an option for turning
off the lights was added.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The new flag, DISABLE_NOTIFICATION_TICKER, will be used by
the car dock app (in conjunction with DISABLE_EXPAND) to
minimize distractions to the driver.
It may also be used by the secure lockscreen to avoid
leaking personal information when the screen is on but the
device is locked (e.g. when the desk dock app is running).
Change-Id: Ibc8efde7da7501767163ae0a75f7c369b824e2a2
|
| |
| |
| |
| |
| |
| |
| |
| | |
The steps to reproduce this were kind of interesting. You needed to have
a notification with a bogus RemoteViews in the first position in the list,
and then have another notification come in with an earlier timestampe. In
that case, it would get a bad index for the new (not bogus) view that was
being added.
|
| |
| |
| |
| |
| |
| |
| | |
current time. Use that for notifications instead of a TextView that
doesn't ever update.
BUG 1563917
|
|/
|
|
| |
Bug: #2361749.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
of the LED incorrect.
(and add a test that helped me debug it)
Original author: joeo
Merged from: //branches/cupcake/...
Original author: android-build
Merged from: //branches/donutburger/...
Automated import of CL 143279
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|