Huge memory usage when updating the same notification to show progress [36924711]

Infeasible

Bug

[AOSP] assigned

[AOSP] Version-2.1

Status Update

No update yet.

Description

cl...@gmail.com

created issue #1

Jan 12, 2011 09:15AM

How to reproduce:
I attached an android eclipse project with an example application. Just run the application to reproduce the issue. Also attached adb bugreport.

What happens:
When updating a same notification and custom view (see

http://developer.android.com/guide/topics/ui/notifiers/notifications.html) to show some progress, there is a huge memory usage. The garbage collector ends up running a lot and the UI becomes unresponsive. Note that if one recreates the Notification and RemoteViews for each progress update (uncomment line 81 of NotifierService.java in the example project), the garbage collection seems pretty reasonable and the UI remains responsive.
See also

http://stackoverflow.com/questions/3608684/huge-memory-usage-in-notifications .

Expected behavior:
I would expect the notification to work fine without recreating Notification and RemoteViews for each update as it is the recommended way to do it in the documentation.

This issue was produced on a NexusOne running Android 2.1-update1.

deleted

Restricted

0 B

deleted

Restricted

0 B

Comments

de...@gmail.com <de...@gmail.com> #2Jul 1, 2011 09:34AM

Information redacted by Android Beta Feedback.

de...@gmail.com <de...@gmail.com> #3Jul 1, 2011 04:31PM

Thank you for reporting this issue. For us to further investigate this issue, please provide the following additional information:

Please upgrade to the latest release from the link V-QPR.If the issue still persists, please capture the new bug report along with the screen record or screen shot and share it here.

ro...@gmail.com <ro...@gmail.com> #4Sep 19, 2011 06:27PM

Upgrade was never offered. I was offered directly Android 16. I can't
install Android 16 as I want to leave beta.

<buganizer-system@google.com> schrieb am Do., 27. Feb. 2025, 08:55:

- Show quoted text -

mo...@gmail.com <mo...@gmail.com> #5Sep 21, 2011 09:39PM

Thank you for reporting this issue. We have shared this with our product and engineering team and will update this issue with more information as it becomes available.

ba...@gmail.com <ba...@gmail.com> #6Nov 14, 2011 10:49PM

Thanks for reporting this issue.

We are handling "No more paying via Wallet because the system is not up to date" wallet issue here.
Please file a separate ticket for "Upgrade was never offered to install android 16" with details.

ro...@gmail.com <ro...@gmail.com> #7Nov 30, 2011 03:52PM

Just want to add, same situation as yours, only it's been happening since December.
After upgrading to stable the issue persists.

ba...@gmail.com <ba...@gmail.com> #8Nov 30, 2011 09:09PM

I don't think we can call this a workaround: use it less, it will crash less ;)
Seriously aren't there any way to display a customNotif with a progressBar that is refreshed for every % without crashing (and forcing some device to reboot) ?

[Deleted User] <[Deleted User]> #9Dec 13, 2011 08:31PM

I'm facing the same issue, the service Status Bar is growing its memory even com.android.systemui is freeing memory frequently. :-(

td...@gmail.com <td...@gmail.com> #10Jan 30, 2012 02:38PM

Managed to completely freeze my phone with this problem. It does seem to work correctly in the ICS emulator though, as far as I can tell.

ki...@gmail.com <ki...@gmail.com> #11Mar 1, 2012 01:30PM

As stated in description: Solved it by reusing the same notification instance but reassigning everything else (content intent, content view).

fa...@brelton.com <fa...@brelton.com> #12Aug 9, 2012 08:02AM

This is still happening on 4.1.1, recreating the remoteView and attaching it to the same notification is a valid workaround; no need to recreate the notification, as that causes it to jump around on the notification panel.

wa...@gmail.com <wa...@gmail.com> #13Sep 22, 2012 01:42AM

[Comment deleted]

wa...@gmail.com <wa...@gmail.com> #14Sep 22, 2012 01:42AM

Double, tripple confirmed that recreating the remote view is a functional workaround. Tested on up to date Jelly Bean on the Galaxy Nexus.

ab...@gmail.com <ab...@gmail.com> #15Jan 22, 2013 11:54AM

[Comment deleted]

we...@gmail.com <we...@gmail.com> #16Mar 12, 2013 10:40AM

4.1.2 also happens...It seems RemoteViews Arraylist of Action is grow to larger and larger, and is there one way to clean the ArrayList inside remoteview automatically?

pa...@gmail.com <pa...@gmail.com> #17Jan 22, 2016 08:23PM

Updating same notification still causes huge leak. Any progress? Thanks.

st...@gmail.com <st...@gmail.com> #18May 2, 2016 07:22AM

Looks like

comment #16

is correct about the ArrayList of Action growing larger and larger so I propose a possible fix here:

The Action class already defines getUniqueKey as a combination of action name and viewId. If Action.equals() and Action.hashCode() were based on getUniqueKey(), then the ArrayList could be replaced with a Set.

By replacing the ArrayList with a Set, any new updates to the same view would replace the previous action in the Collection instead of appending ad infinitum.

jo...@google.com <jo...@google.com> Apr 18, 2017 01:27AM

Status: Won't Fix (Infeasible)