summaryrefslogtreecommitdiffstats
path: root/packages/SystemUI
diff options
context:
space:
mode:
authorDaniel Sandler <dsandler@google.com>2011-07-20 14:41:41 -0400
committerDaniel Sandler <dsandler@google.com>2011-07-20 14:41:41 -0400
commit20cdb151c9f1a956eee9eebe77459e14029ad131 (patch)
tree0e3c94db3db02a3802f0799954d88dc95321bf9d /packages/SystemUI
parent5a8ca580b078c7335d8ee384dd93dc86663d8d53 (diff)
downloadframeworks_base-20cdb151c9f1a956eee9eebe77459e14029ad131.zip
frameworks_base-20cdb151c9f1a956eee9eebe77459e14029ad131.tar.gz
frameworks_base-20cdb151c9f1a956eee9eebe77459e14029ad131.tar.bz2
Fix dancing download notifications on phones.
There's always going to be some amount of visual noise when notifications change order, and this can happen any time a notification changes its "when" field (as is the case for download progress bars). But in HC we added an optimization that will reuse the current row if the download is the last item in the list (so a fresher "when" will still put it at the end), and that optimization is re-applied here. Now, if you have multiple notifications all competing for the top spot, I can't help you. But we had that problem before (it just wasn't as egregious because we didn't have the shiny animations). Bug: 4971404 Change-Id: I5bcc905bdb19a8eb5b4494a6ba9825b4d5373caa
Diffstat (limited to 'packages/SystemUI')
-rw-r--r--packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java20
1 files changed, 13 insertions, 7 deletions
diff --git a/packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java b/packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java
index b50fd81..f4c4bbc 100644
--- a/packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java
+++ b/packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java
@@ -565,27 +565,33 @@ public class PhoneStatusBar extends StatusBar {
final RemoteViews contentView = notification.notification.contentView;
- if (false) {
+ if (DEBUG) {
Slog.d(TAG, "old notification: when=" + oldNotification.notification.when
+ " ongoing=" + oldNotification.isOngoing()
+ " expanded=" + oldEntry.expanded
- + " contentView=" + oldContentView);
+ + " contentView=" + oldContentView
+ + " rowParent=" + oldEntry.row.getParent());
Slog.d(TAG, "new notification: when=" + notification.notification.when
+ " ongoing=" + oldNotification.isOngoing()
+ " contentView=" + contentView);
}
+
// Can we just reapply the RemoteViews in place? If when didn't change, the order
// didn't change.
- if (notification.notification.when == oldNotification.notification.when
- && notification.isOngoing() == oldNotification.isOngoing()
- && oldEntry.expanded != null
+ boolean contentsUnchanged = oldEntry.expanded != null
&& contentView != null && oldContentView != null
&& contentView.getPackage() != null
&& oldContentView.getPackage() != null
&& oldContentView.getPackage().equals(contentView.getPackage())
- && oldContentView.getLayoutId() == contentView.getLayoutId()) {
- if (SPEW) Slog.d(TAG, "reusing notification");
+ && oldContentView.getLayoutId() == contentView.getLayoutId();
+ ViewGroup rowParent = (ViewGroup) oldEntry.row.getParent();
+ boolean orderUnchanged = notification.notification.when==oldNotification.notification.when
+ && notification.priority == oldNotification.priority;
+ // priority now encompasses isOngoing()
+ boolean isLastAnyway = rowParent.indexOfChild(oldEntry.row) == rowParent.getChildCount()-1;
+ if (contentsUnchanged && (orderUnchanged || isLastAnyway)) {
+ if (DEBUG) Slog.d(TAG, "reusing notification for key: " + key);
oldEntry.notification = notification;
try {
// Reapply the RemoteViews