summaryrefslogtreecommitdiffstats
path: root/tests/StatusBar
Commit message (Collapse)AuthorAgeFilesLines
* remove usage of deprecated method setLatestEventInfoChris Wren2015-06-124-282/+291
| | | | | Bug: 18510449 Change-Id: I56a77991c729990e501f402e007dfa79ee57621e
* Change constant to PowerManager.RELEAES_FLAG_WAIT_FOR_NO_PROXIMITYMichael Wright2014-09-121-4/+5
| | | | | Bug: 17290118 Change-Id: Iae3866bf3f7ac24f756ec4c183e848a79d1f779b
* Change constant to PowerManager#FLAG_WAIT_FOR_DISTANT_PROXIMITYMichael Wright2014-08-271-4/+4
| | | | | | | Also add docs to PowerManager.WakeLock#release(int) Bug: 17290118 Change-Id: Ibcbc4279efdd0f275808042356e6ff843958e23f
* Fix [-] buttons in the notification builder test.Daniel Sandler2013-04-091-10/+14
| | | | | | | (Broken by change I9fae5a4a). Bug: 8564511 Change-Id: I0d5b65e6678018630c812c5616e9b3f068029e66
* Add tag "foo" to builder test's notifications.Daniel Sandler2013-04-081-1/+3
| | | | | | | | | | | | | This allows them to be conveniently cleared via adb: $ adb shell service call notification 5 \ s16 com.android.statusbartest \ s16 foo \ i32 <NOTIFICATIONID> \ i32 <USERID> Bug: 8564511 Change-Id: I9fae5a4a0be64d6707cc06ca938adeb8b3c0b735
* New NotificationListenerService.Daniel Sandler2013-04-051-3/+0
| | | | | | | | | | | | | | | | | | | | | 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
* App ops: vibration, neighboring cells, dialing, etc.Dianne Hackborn2013-02-011-2/+5
| | | | | | | | | | | | | | | | | Improve handling of vibration op, so that apps are better blamed (there is now a hidden vibrator API that supplies the app to blame, and the system now uses this when vibrating on behalf of an app). Add operation for retrieving neighboring cell information. Add a new op for calling a phone number. This required plumbing information about the launching package name through the activity manager, which required changing the internal startActivity class, which required hitting a ton of code that uses those internal APIs. Change-Id: I3f8015634fdb296558f07fe654fb8d53e5c94d07
* Clean up the Builder test.Daniel Sandler2012-11-143-495/+654
| | | | | | | | | Improved vibration coverage Fixed LED color Added priority Added a start delay (for testing LED while screen off) Change-Id: I3dab0a1a7494f0fe7631d1af49c0fb9a1fdd3f63
* Properly show emoji in the notification ticker.Daniel Sandler2012-10-192-8/+46
| | | | | | | | | Add an emoji test to StatusBarTest (working around some difficulties in actually putting high-Unicode chars in the layout xml). Bug: 7378383 Change-Id: Ifce9844b26f67d2799521623e5161aa4dad69ed1
* New internal API to eliminate poke locks.Jeff Brown2012-10-011-66/+0
| | | | | | | | | | | Added a new WindowManager.LayoutParams inputFeatures flag to disable automatic user activity behavior when an input event is sent to a window. Added a new WindowManager.LayoutParams field userActivityTimeout. Bug: 7165399 Change-Id: I204eafa37ef26aacc2c52a1ba1ecce1eebb0e0d9
* Cleanup internal status bar APIs.Daniel Sandler2012-09-271-6/+20
| | | | | | | | | | | 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
* Adding a global accessibility action to open quick settings.Svetoslav Ganov2012-09-251-17/+3
| | | | | | | | | | | | | | | | 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
* Remove Binder.getOrigCallingUid().Dianne Hackborn2012-08-311-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Power manager rewrite.Jeff Brown2012-08-151-17/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The major goal of this rewrite is to make it easier to implement power management policies correctly. According, the new implementation primarily uses state-based rather than event-based triggers for applying changes to the current power state. For example, when an application requests that the proximity sensor be used to manage the screen state (by way of a wake lock), the power manager makes note of the fact that the set of wake locks changed. Then it executes a common update function that recalculates the entire state, first looking at wake locks, then considering user activity, and eventually determining whether the screen should be turned on or off. At this point it may make a request to a component called the DisplayPowerController to asynchronously update the display's powe state. Likewise, DisplayPowerController makes note of the updated power request and schedules its own update function to figure out what needs to be changed. The big benefit of this approach is that it's easy to mutate multiple properties of the power state simultaneously then apply their joint effects together all at once. Transitions between states are detected and resolved by the update in a consistent manner. The new power manager service has is implemented as a set of loosely coupled components. For the most part, information only flows one way through these components (by issuing a request to that component) although some components support sending a message back to indicate when the work has been completed. For example, the DisplayPowerController posts a callback runnable asynchronously to tell the PowerManagerService when the display is ready. An important feature of this approach is that each component neatly encapsulates its state and maintains its own invariants. Moreover, we do not need to worry about deadlocks or awkward mutual exclusion semantics because most of the requests are asynchronous. The benefits of this design are especially apparent in the implementation of the screen on / off and brightness control animations which are able to take advantage of framework features like properties, ObjectAnimator and Choreographer. The screen on / off animation is now the responsibility of the power manager (instead of surface flinger). This change makes it much easier to ensure that the animation is properly coordinated with other power state changes and eliminates the cause of race conditions in the older implementation. The because of the userActivity() function has been changed so that it never wakes the device from sleep. This change removes ambiguity around forcing or disabling user activity for various purposes. To wake the device, use wakeUp(). To put it to sleep, use goToSleep(). Simple. The power manager service interface and API has been significantly simplified and consolidated. Also fixed some inconsistencies related to how the minimum and maximum screen brightness setting was presented in brightness control widgets and enforced behind the scenes. At present the following features are implemented: - Wake locks. - User activity. - Wake up / go to sleep. - Power state broadcasts. - Battery stats and event log notifications. - Dreams. - Proximity screen off. - Animated screen on / off transitions. - Auto-dimming. - Auto-brightness control for the screen backlight with different timeouts for ramping up versus ramping down. - Auto-on when plugged or unplugged. - Stay on when plugged. - Device administration maximum user activity timeout. - Application controlled brightness via window manager. The following features are not yet implemented: - Reduced user activity timeout for the key guard. - Reduced user activity timeout for the phone application. - Coordinating screen on barriers with the window manager. - Preventing auto-rotation during power state changes. - Auto-brightness adjustment setting (feature was disabled in previous version of the power manager service pending an improved UI design so leaving it out for now). - Interpolated brightness control (a proposed new scheme for more compactly specifying auto-brightness levels in config.xml). - Button / keyboard backlight control. - Change window manager to associated WorkSource with KEEP_SCREEN_ON_FLAG wake lock instead of talking directly to the battery stats service. - Optionally support animating screen brightness when turning on/off instead of playing electron beam animation (config_animateScreenLights). Change-Id: I1d7a52e98f0449f76d70bf421f6a7f245957d1d7
* Fix NPEs in StatusBarTest.Daniel Sandler2012-05-041-7/+15
| | | | Change-Id: I9245a297a9a09c09415dd38e662692665ae7e109
* Expand too-small notifications to fill 64dp.Daniel Sandler2012-04-191-2/+10
| | | | | | Also fix NotificationTestList so it runs again. Change-Id: I2fb28cd9cfad25a7a1b17ccef9ccd741c3aa99b0
* Extract Vibrator implementation from interface.Jeff Brown2012-04-131-1/+1
| | | | | | | | | | | | | | Moved the core logic of Vibrator into SystemVibrator, potentially allowing for the creation of other Vibrator subclasses. Fixed several places where we were creating new Vibrator instances unnecessarily instead of getting it from the Context. It is safe to make Vibrator abstract because its constructor was hidden from the SDK so it was not possible to subclass it. Bug: 6334179 Change-Id: I18ece6544c26a7efb2d5099f8346a10aef8a5e18
* New notification priority and related APIs.Daniel Sandler2012-02-241-5/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change introduces a few new bits of data on Notification that will help the Notification Manager and System UI route and display them more intelligently: -> priority: an integer in a predefined range that indicates the app's best guess as to the relative importance (to the user, right now) of that information -> kind: a tag (really, set of tags) indicating the general type of notification (realtime, asynchronous, etc) -> extras: a Bundle of additional key/value pairs associated with this notification (currently @hidden) The notification manager takes these data into account when assigning to each notification a score which is passed with the notification on to the system UI, where it can be used to affect presentation. For example: - Spammy apps (identified explicitly by the user or by some other means) will have their notifications scored very negatively by the notification manager, allowing the UI to suppress them - Notifications of higher score might be shown larger or in a different way - Very important notifications (indicated by a very high score) might interrupt the user during an otherwise important task (videochat, game, etc) Implementation note: This replaces/extends the old internal notion of "priority", which was mostly used to organize ongoings and system notifications at the top of the panel. Change-Id: Ie063dc75f198a68e2b5734a3aa0cacb5aba1ac39
* Improve handling of small largeIcons in tablet ticker.Daniel Sandler2011-12-072-0/+8
| | | | | | | | | | | | | | | | | | | | | The tablet system bar is too short for a full notification row, but it will show the largeIcon of a new notification in its full frame, intruding into the main application content rectangle a bit. This is a good thing---the notifications really pop out at you---but it looks a little odd if the largeIcon is actually *small*: the icon is vertically centered in the larger (invisible) rectangle, making it look poorly centered on the system bar. This change will detect short largeIcons and center them in the system bar's height instead. Additionally, it applies the same ticker background all the way to the left underneath largeIcons that are not full-frame (and therefore have transparent regions). Bug: 5708907 Bug: 5560485 Change-Id: I32af45632df164c58fb960110063dbaa08b5536c
* Break apart DISABLE_HOME and DISABLE_RECENT.Daniel Sandler2011-10-131-5/+10
| | | | | | | | | | | | | Additionally, start using setSystemUiVisibility() where possible in the keyguard to allow activities and dialogs to re-enable some of the navigation keys (notably: home but not recents). Finally, stop disabling MENU for activities atop the keyguard. Bug: 5380495 // no home in driveabout, clock Bug: 5396134 // able to show home/recent in keyguard Change-Id: I04eb224554ee8cff79476b85148c4cda75bb0b62
* Hide navigation buttons when they are DISABLEd.Daniel Sandler2011-09-121-1/+6
| | | | | | | | | Back is hidden by DISABLE_BACK; Home, Recents, and Menu are hidden by DISABLE_NAVIGATION. Bug: 5261576 Bug: 5284740 (confusion about visible inactive icons) Change-Id: I410c133b737cc11d61bac0318dc24458353ee7b3
* Fix fullScreenAlert test.Daniel Sandler2011-08-101-4/+7
| | | | Change-Id: I3df0a998347c9e3d21e067381bd22eb9a0862f0d
* The fullest of fullscreen modes.Daniel Sandler2011-07-281-15/+37
| | | | | | | | | | | | | | | | | | | | | | | 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
* Adding accessibility support to the Status Bar.Svetoslav Ganov2011-07-211-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Make the Notify Builder test usable on phones.Daniel Sandler2011-06-1617-219/+279
| | | | Change-Id: Ibaa3b2b99bde7dfd3d9fc6bc4c0068fc1d7b914d
* Merge "Fix the status bar test app."Daniel Sandler2011-06-041-9/+4
|\
| * Fix the status bar test app.Daniel Sandler2011-02-071-9/+4
| | | | | | | | Change-Id: Ib7d047a5ed21393ea9cbcdc343cb0cfbb7c62ff7
* | It's lights out for you, navigation bar!Daniel Sandler2011-05-111-1/+8
| | | | | | | | | | | | | | | | | | | | | | 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
* | Ongoing notification for GPS use.Daniel Sandler2011-02-031-0/+37
|/ | | | | | | | | | | | | | | | | | | | This change improves upon the notification priority API introduced in change I9e738cc4, allowing privileged clients to set the priority of a notification when posting it directly to INotificationManager. StatusBarTest is updated to test this new feature. The new LocationController in SystemUI uses this facility to post a high-priority ongoing notification whenever GPS is in use (replacing the functionality of the legacy GPS status bar icon). Also happens to fix http://b/3325472 (adding a log message when notifications are dropped because of a missing icon). Bug: 3412807 Change-Id: I523016ffa53bf979be98ddc4a2deb55a6270c68a
* Allow the status bar disable flags to be used as View's system ui visibility ↵Joe Onorato2011-01-271-1/+7
| | | | | | | fields. Bug: 3363046 Change-Id: I50ba06ed9a4d2f5d0e0c807437aea9900f44fee9
* Fit and finish on status bar:Daniel Sandler2011-01-252-0/+0
| | | | | | | | | | | | | | | | | | | | | - Clock color fixed. [3374581] - Clock vertically aligned. [3388224] - Clock uses system font assets now. [3385564] - Solid version of AndroidClock added to build. [3385564] - Extraneous background glow removed from notification panel. - Removed solid black background from notifications. [3388223] - Added background image behind large notification icons and increased large size to 64dip [3388434, 3384355] - Corrected size & leading of notification text [3388577] Bug: 3374581 Bug: 3384355 Bug: 3385564 Bug: 3388223 Bug: 3388224 Bug: 3388434 Bug: 3388577 Change-Id: I8e443da5758deca412d1ce5944f887b35f6265ed
* visibility ("lights out") API.Joe Onorato2011-01-231-0/+24
| | | | | | | | | | | | | | | | 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
* Need to update the largeIcon for notifications when we're reapplying the views.Joe Onorato2011-01-153-2/+18
| | | | | Bug: 3298062 Change-Id: I6bb72c0b93e00a9de8cc2633ac07add0a572a20f
* Possibly fix bad notification updates.Joe Onorato2011-01-121-1/+1
| | | | | | | | | I think what was happening is that it was using a different layout but we were trying to reapply the RemoveViews because of some bad boolean logic. This fixes that, and adds some better debugging that might show us what else is happening. Bug: 3298062 Change-Id: I0984f24cb2960166c79b9f2cc7c6a98bd75e17ba
* Make AppWidgetService handle components enabling and disabling.Joe Onorato2011-01-102-0/+21
| | | | Change-Id: Ie6b75cb90be38bbce694ccf2d5a342d7f0172fa4
* Reimplement StatusBarManager.disable(DISABLE_SYSTEM_INFO).Daniel Sandler2010-12-161-0/+5
| | | | | Bug: 3284968 Change-Id: I7171b7770c2972bb56672a771c7ed5ca10fb4dda
* Hide navigation buttons and clock on lockscreen.Daniel Sandler2010-12-031-6/+7
| | | | | | | | | (This introduces a StatusBarManager disable flag to ask the status bar to hide just the clock, which might be useful in other situations, such as clock/dock apps.) Bug: 3130393 Change-Id: Ia08627508518e2ed3713ffbf856e4ec42952b3a8
* Fix build.Daniel Sandler2010-11-301-0/+22
| | | | Change-Id: Iccbe1609bbe582180d1c61f908b8dce4d485494b
* When updating notifications, always reuse the last row.Daniel Sandler2010-11-301-0/+48
| | | | | | | | | | | | Ordinarily, changing the "when" slot when updating a Notification will move its expanded payload to the bottom of the notification panel's list. But if it's already at the bottom, this causes an unsightly out-then-in animation sequence. We now check for that exact situation. Bug: 3222274 Bug: 3162218 Change-Id: I8b643b3f8bce64e57a22bdbb06d92c196c2484c2
* Add a better notification test and clean up the flag handling in the ↵Joe Onorato2010-11-225-64/+1216
| | | | | | notification builder. Change-Id: I9354ed2c2cda690f53e5f43ad60943b63b02e7d4
* The large icon for notifications.Joe Onorato2010-11-212-26/+32
| | | | Change-Id: I8537c602b5b5fca03be8980295bfa28330543669
* Test for using the right size of notification info text.Joe Onorato2010-11-211-1/+18
| | | | Change-Id: Iac8764542ddcd3ef0375f6d6d03225e9f6c2fc1c
* Show the number in the expanded notification instead of in the bar.Joe Onorato2010-11-211-0/+19
| | | | Change-Id: I248b4fe1732ed290e9f3f9c094de4544a0e396ab
* Update the look of the notifications. Includes adding a new ↵Joe Onorato2010-11-215-89/+165
| | | | | | Notification.Builder class. Change-Id: I7c57b81c45defe77d6f3d22472e9cf8432bbed03
* The CHEEK_TOUCH stuff never worked. Remove it.Joe Onorato2010-11-081-24/+4
| | | | | Bug: 3104906 Change-Id: Ia37236ba1775fc3ec8c111e2e0b85b105e0dea6a
* Allow both contentIntent and setOnClickPendingIntent in notificationsJoe Onorato2010-10-312-0/+34
| | | | | | | | | | From the app developer's request: Intents assigned to specific views should take precedence over the content intent, but it should not be required to set the content intent to null in order for the view-intents to work Bug: 3107945 Change-Id: Ic5282d441277a9a8c8c700ef3f43872f3405b58a
* Notification flyovers.Daniel Sandler2010-10-2914-4/+33
| | | | | | | | | | | Hold your finger on an individual notification icon to quickly show that notification's payload. Also: Quickly swipe up on any icon to open the tray. Bug: 2994009 Change-Id: I2ae2b546fcfa62994b63b9376f487289b2d06796
* Allow notifications to not specify a contentIntent.Joe Onorato2010-10-131-0/+18
| | | | | | | | | | | If they don't, the click events will be passed through to the individual views in the notification view, which may have their own PendingIntents attached. Previously, it was against the UX spec to allow this, but now we are changing that and will have buttons in there. Change-Id: I674234212f64b2b8802a0708b7eed0614e147ca3
* Revert "Merge "Allow notifications to not specify a contentIntent.""Jason Chen2010-10-081-18/+0
| | | | | This reverts commit 8885321046622d6a8c0a4214af98dc27eecd48a0, reversing changes made to 61b8aaadd742f0be708cd37971d2c9e822bf778a.
* Allow notifications to not specify a contentIntent.Joe Onorato2010-10-081-0/+18
| | | | | | | | | | | If they don't, the click events will be passed through to the individual views in the notification view, which may have their own PendingIntents attached. Previously, it was against the UX spec to allow this, but now we are changing that and will have buttons in there. Change-Id: Ie3b2e96c6a1c4449fa86ed571f3ad0f047320d31
generated by cgit v1.1 at 2024-05-17 23:08:59 +0000