IssueTracker

I proposed this which I think it is better than the actual behavior, and could let the developers work with more room to be creative.

https://code.google.com/p/android/issues/detail?id=58318

The presentation link doesn't work.

In Custom Notification Layouts section of the Notification API Guides, it states: "The height available for a custom notification layout depends on the notification view. Normal view layouts are limited to 64 dp, and expanded view layouts are limited to 256 dp". I guess it means the width is 512 dp and the height is 256 dp (if following the 2:1 aspect ratio)?

http://developer.android.com/guide/topics/ui/notifiers/notifications.html#CustomNotification

Here is the presentation:
http://commondatastorage.googleapis.com/io2012/presentations/live%20to%20website/105.pdf

Any update on this?

Thank you for your feedback.  We assure you that we are doing our best to address all issues reported. For now, we will be closing the issue as won't fix obsolete. If this issue currently still exists, we request that you log a new issue along with the bug report here https://goo.gl/TbMiIO and reference this bug for context.

I had the same issue, and I took "fisherme...@gmail.com"'s advice. I am now promoting FireFox to my users. I love Chrome, but it sounds like FireFox teams listen to what developers/users want.

altough it seems impossible to save the file at the current state of things it is possible to detect this situation and alert the user.

you can save to a cookie / local storage a flag saying upload is in progress and first thing you do when you open the site is checking that flag, if its checked you know the browser has been restarted and you can alert the user to free memory/ try other browser / bang his head into the wall..

smart usage of local storage could save the entire state of your webapp in case the browser is closed so you can return to the same state and not lose your user data.

I too have same issue on my android 4.2 device. can any one have solution to this ?

this problem happening with me as well, It's only happening If you are using camera to upload picture while if you select any file with same size like the image it will be uploaded successfully.

I have this problem too, Did this fixed in 4.3+ ?

Hope some told me . plz.

This may occur if you have enabled "Don't keep activities" in the Developer options.

I've the same problem. I use chrome and when I upload a file the browser refresh and I'm not able to upload my file :(. If a native app is able to do it, why chrome is not able to ?

On one hand this issue is an example of how badly conceived the Android framework is (specifically the activity lifecycle, with the stupid idea that an activity that has started another activity is eligible for being killed). On the other hand, once one accepts Android is designed that way, the browser is failing to its job as an application: which includes retaining its state. Note that it not only means not reloading the page (reloading the page is a HUGE flaw) but also remembering the current state of things like checkboxes, inserted texts, any change to the document performed by javascript, and the entire javascript current state (i.e. variables and the like). A browser MUST retain all that; failure to do so is an unacceptable behavior for a browser. Now think how tremendously difficult it will be to fix that given how the OS works:  this gives a measure of how badly designed the OS's activity-lifecycle thing was in the first place.

What #15 said. Can't believe we have to work around something like this... O_O

4.4.2 and stil no fix ! On 1GB phone I have most of MEM free but reload still happens.  This is extremly annoying .

This issue has three layers.
From bottom to top:

1.(OS-level, probably won't ever be fixed in years as it is by [bad] design) The activity that launched the current activity will always be eligible for being killed, and it may always happen that it ends being killed, no matter how much memory you have. That's a terribly bad design in the Android framework itself at the deepest level. It's ridiculous that activities that are in the very stack that launched the current activity, especially the last-but-one, are not strongly prioritized in keeping them alive. However, Android does provide (tremendously convoluted) mechanisms for activities to deal with that, so see point 2.

2. (WebView-level) every activity has the responsibility and duty to use those mechanisms in order to save and restore its state if it does get destroyed and recreated. BUT WebView does not provide any built-in mechanism to save its complete state so that it can be restored. So, any application using webview will have a very hard time trying (or most probably won't ever be able) to work this around in order to behave the way any decent browser is expected to behave (i.e. retain its state as if nothing had happened when it launches an intent and you come back).
WebView has been designed without taking into account the activity lifecycle of the Android OS.

3. (Browser-level). Android Browser as an app does not do even the slightest attempt to work around issue (2), which is in my opinion the most astonishing thing. I wonder whether those who developed the Android browser don't understand how a browser is expected to behave, or if they forgot about the existence of the activity lifecycle, or if they just didn't realize that within the normal use of a browser it can happen (let alone that it's very common) that an intent is launched.

If those who wrote the browser had tried to deal with this issue, perhaps one of two things may have happened:
(a) they would have come up with a complete workaround for WebView's basic deficiency (issue level 2), providing a fair amount of valuable source code that developers of practically every other app using a webview would have to copy and paste, or
(b) they could have realized how huge is the issue in WebView itself and would have fixed it at that level.

It's really amazing that such a simple action as opening a file select dialog/app on a device with 1GB or even more RAM with no other apps running, causes browser to be closed because of insufficient memory.

I wrote a web app that allows users to share files between devices using peer-to-peer connections and I can send a file of size over 500MB to an Android device through a browser, but I can't even select 1KB file to send it to a computer.

[Comment deleted]

> It's really amazing that such a simple action as opening a file select
> dialog/app on a device with 1GB or even more RAM with no other apps running,
> causes browser to be closed because of insufficient memory.

This is because of the ridiculously stupid algorithm that manages process lifecycle, as documented here:
http://developer.android.com/guide/components/processes-and-threads.html#Lifecycle

Whenever an activity gets paused (which is, when another activity comes to the foreground), even if it is paused because it itself launches another activity from which it expects a result, it is eligible for killing EXACTLY as well as ANY other background process. The fact that that paused activity is the very one that launched the current activity, or that it is expecting a result from the current activity, or that it has been paused a matter of seconds ago, none of this is taken into account the slightest bit when the OS wants to free up some memory and picks some process to kill.
 
The most surprising fact about this astonishing design flaw is that it hasn't been addressed. A lot of things get changed continuously which break backwards compatibility unnecessarily, and this one, which could be changed yielding a huge improvement and without any BC concern, doesn't get addressed.


Then, the same people who designed this, don't take this into account when they create the WebView nor the Browser application.

Oh, but I'm repeating myself.


There's a kind of (hugely incomplete) workaround that you just might be interested in:
If the activity used for browsing and selecting a file is not fullscreen and leaves the browser activity visible on screen "behind" it, the browser won't be eligible for killing (at least until there's no other process that can be killed and memory is really needed).

There's an app called ES File Explorer which does that. If it is acceptable for you to instruct the users of your web application to install ES File Explorer (or any other app that behaves in a similar way), and select it when they are prompted to choose an application for browsing for the file to upload, then that will do the trick.

This issue should at least have Priority-High as it concens all apps that have file uploading features!! No fix in  4.4.4  - extremely disappointing.

is there any solution to work around this?

This is the most disappointing behavior of web technology I ever ran into.
It makes my whole web app useless because its only purpose is to take a single picture and upload it to a server. And I don't know how to tell a customer that it's not possible to take and upload a photo with his high end smartphone.

PS:
I can confirm this behavior for a Motorola Moto G 2nd generation (Android 4.4.4, 1 GB RAM) and for a Samsung Galaxy S3 (Android 4.3, 1 GB).  On the Moto G it happens even after a factory reset with no other apps installed or running except the pre-installed Chrome and 300 MB of free RAM.

Even I am facing this issue on some of the top phones out in the market. When are you going to roll out a fix for this?
Meanwhile, Unlike other browsers, Chrome shows an message when it runs out of memory. and in the latest version, they are handling it gracefully by preserving the data.

[Comment deleted]

I am not getting this issue on my custom ROM of CyanogenMod 11 on Samsung galaxy S2 (Android >4.2, 1GB RAM). How they resolved this issue. Please make use of this ROM to solve the issue.

Any update if this issue is going to be resolved in Lollypop?

Thank you for the feedback. Oh wait...

My same code works on iOS webview and safari fine (along with desktop browsers). But when it comes to chrome on iOS or webview of Android, there are problems.

Being low on memory, reading entire file in memory could cause a problem, that is understandable, but problem is just on selecting any file it crashes (reloads page). That does not seem right, this bug should be fixed so developers can support file (image/audio) from chrome on mobile as well as web view of android application.

If this is fixed would be much appreciated.

Why on earth has the status been changed to "Obsolete"?

This problem still exist in Lollipop

Yes I reproduced it on a Wiko !

Reproducible on KitKat (4.4.4), Sony Experia Z2, with both the built-in chrome as well as dolphin browsers.

Unsetting "Don't keep activities" in the developer options or disabling developer mode makes the problem disappear.

I also have this issue on Android 4.1.1 / Chrome (browser refresh and memory error message) and also on Safari (open dialog fails to appear) with a GPS webapp.
Firefox works ok, loading text/xml/binary files with the html5 filereader, no memory error.
Tip from #37/peter fixed the issue on Chrome. Thanks Peter !
Can't believe such a major issue was not fixed - and why a memory error when loading a 1K text file !

m.facebook.com seems to fine the way around it.....

[Comment deleted]

@39 no, it doesn't. It fails in Facebook and Twitter, as in every other web.
If it works for you, you just were randomly lucky that the OS didn't decide to kill the browser in order to free memory

@37 (and @13)

> Unsetting "Don't keep activities" in the developer options or disabling developer mode makes the problem disappear.

NO IT F***ING DOESN'T.
I wish people stopped spreading this superstitious bulls***.

While the "don't keep activities" will make this issue occur systematically, and unchecking it might well make it happen much less frequently, it does NOT make it disappear.

I have "don't keep activities" unchecked (I never checked it in the first place) and I observe the issue all the time.

@42
You're right, the issue is still there even with "don't keep activities" trick, although it seems to disappears sometime with installed webapps.
This makes Chrome not very usefull for webapps which use the filereader...

This is not an Obsolete issue. This should be marked as Open.

This isn't really a Google Chrome problem...  it's an Android problem.  I have no doubt that Google would have fixed the file upload/memory issue if they could.

This issue is prevalent in all mobile browser that I have tried: Firefox, Chrome, and Dolphin.

I found two ways, to reduce the forced page refreshs:

- lower resolution in camera app: less resolution means less memory usage and on a Samsung Galaxy S5 it helped. 16 Megapixel as default was too much.

- allow Chrome to use more RAM: http://www.reddit.com/r/Android/comments/21r0a6/how_i_sped_up_chrome_on_my_device

Not the best way, but it seems to work. Actually, I don't like the idea to let the user make those tweeks to use it and not on application side.

Same issue in Android Kitkat for browsers, in app webview cordova/crosswalk reboot the app.

This issue is not obsolete at all!!!
Please, it has to be addressed. Whenever I open a file from a browser it gets killed, with various devices. Do somethig!

Even Maybe create an in-browser file chooser.
Like HERE -> https://db.tt/G6ZgaXO5 
Anything that will overcome the killing

Pretty please, with sugar on top!!

I'm afraid nobody at Google is watching this issue.
It looks like they have a stupid policy that when they close an issue, they unsubscribe from it and never get notification of replies (or they redirect them automatically to their trashcan, I just can't believe they simply ignore them).

So everybody please star this one:
https://code.google.com/p/chromium/issues/detail?id=476390

This has to be fixed as soon as possible. It is very sad that in 2015 we can still come across problems like this!

are there any solution for this problem, please help me :(

@50 no there are no solutions, until the retarded responsible for maintaining Android and Chrome understand the impact of the issue (which has been overlooked for years). The only thing you can do is star the only two bugs that have not been dismissed (yet at least) by some idiot:

The one in Chrome:
https://code.google.com/p/chromium/issues/detail?id=476390

And the one in Android which is the real root cause:
https://code.google.com/p/android/issues/detail?id=170477

Ive been having this problem with my tablet all week. Thank goodness I finally found this page! I switched browsers, cleaned my cache, etc. I think I should invest in an SD card and move all my files and apps to it. Its a fairly new tablet but it only has 2gb to work with. Im assuming thats not enough.

Alas!
Why Google doesn't care about this problem? Over years it keeps alive? No one find the solution for this problem!

are there any solution for this problem??

what time can google fix it.

It is still happening.
Google should prioritize it higher....

@51: Matteo, Thanks for creating these issues.

[Comment deleted]

Yes still happening on samsung S4 device/android version 5

I think I found a solution. Chrome is now allowing me to upload pics to Facebook after doing this! What you do is create a bookmark and put the following:

javascript:window.setInterval(function () {window.stop()},10)

As the URL. Good luck I hope it works.

Hi misspark.

Tried it die not solve my issue.
My issue occurs when i use html5 image capture (camera) multiple times.
Testes this on huawei mate 7 Android 4.4.2
Samsung s5 lollipop 5.0
Sonim xp7
But somehow my Galaxy tab 4 does not have the issue Android 4.2.2
Van this be a Android version issue?

Please everybody affected:

instead of saying "me too" here in this closed and ignored bug report, please star these ones:
https://code.google.com/p/chromium/issues/detail?id=476390
https://code.google.com/p/android/issues/detail?id=170477

Android developers are not willing to aknowledge the underlying issue in Android's architecture, so let's make them see how big the impact of the issue in WebView is, so that they will run nuts trying to fix it at the WebView level, at which point perhaps they'll  realise that it's next to impossible (and yet it's their "obligation" according to the OS's specifications regarding Activity lifecycle) unless they fix the root issue in Android.


@60 I have seen the issue on at least 4.1.x and 4.4.4, it doesn't have anything to do with the version. It's merely random whether you observe it or not, because it depends on whether the browser's process gets killed while it's not on the foreground, and that is something that depends on so many volatile factors that it is practically random.

The OS kills paused activities in order to free up memory, regardless of whether there is an urgency of freeing memory or not, and the demential part is that an activity that is last-but-one in the stack (e.g. the browser), which launched the current activity (e.g. the Camera), even if waiting for it to return a result, isn't granted the slightest benefit in its eligibility for killing. Nor does WebView take any action (as an activity is supposed to do) to save its state before being paused.

So, you may never observe the issue for months on a given phone, and then on the very same phone it may start to happen very often or even systematically, and then again it may disappear.

I mailed the authors asking to reply on this thread with the status of this bug.

2017 and this is still a pain in the ass

I am also facing this issue. Please help to fix this problem.

OMG. I got this on android 6 and android 7 8GB RAM.

Will be a solution some day?

2018! Over 5 years, and this issue isn't still fixed!!

This is asus zenfone with 3GB RAM with nothing else running. I cannot view my website.
On the other hand. windows 10 with 2GB ram can view and play with the same site.

2019! Over 6 years, and this issue isn't still fixed!!

2021, still not fixed? I had capture selfie (1 file), the browser restart. 1.6 - 2 GB free memory.

This issue drives me mad! Most of my file selections just vanish, starting to think if Apple handles this memory better...
Is there any memory setting /app to use to change this behavior?

2023 e nada de resolução

please fix this issue!

this issue is marked as obsolete and they won't fix it... Maybe we should create a new one.
Nobody got a workaround working? I'm just uploading a 1,2MB file and my Android crashes everytime...

We are having this problem on a PWA, it is incredible that still is not fixed. This makes the whole point of having PWA meaningless.

PSA: They will never fix this, so I suggest that you guys just manage the file and state with sessionStorage. That's what we do on our PWA for photo/image uploads on a chat. It's mildly infuriating, but clean enough not to throw yourself out of the window.