Status Update
Comments
rj...@gmail.com <rj...@gmail.com> #2
unfortunately, openFileChooser is not a public API. We are working on a public API in future releases of Android.
rj...@gmail.com <rj...@gmail.com> #3
ok :(
hb...@gmail.com <hb...@gmail.com> #4
So just to be clear, this feature (the file input element opening the file picker) was intentionally removed from webviews in Android 4.4?
I need to be clear on this because this is going to be a pretty significant problem for any Cordova/Phonegap developer (who might not, at the moment, have experienced this problem because 4.4 is still so new).
Is it going to be removed for Android 4.3 and below?
I need to be clear on this because this is going to be a pretty significant problem for any Cordova/Phonegap developer (who might not, at the moment, have experienced this problem because 4.4 is still so new).
Is it going to be removed for Android 4.3 and below?
ma...@gmail.com <ma...@gmail.com> #5
When will this be added back into Android, and what can we do in the mean time?
Before, people were overridding hidden methods - is there just some new hidden method that we have to override to get it working again?
Before, people were overridding hidden methods - is there just some new hidden method that we have to override to get it working again?
sp...@gmail.com <sp...@gmail.com> #6
We are working on a mechanism to support this, maybe as a public API. Unfortunately there is no workaround I know of at the moment. However, if developers have any preference for one of the options below, please let us know:
1. having a WebViewClient style callback to let the app programmatically handle the file input selection
2. having a policy hardcoded into the webview e.g. that just popups the UI automatically when the file input button is pressed
1. having a WebViewClient style callback to let the app programmatically handle the file input selection
2. having a policy hardcoded into the webview e.g. that just popups the UI automatically when the file input button is pressed
dr...@gmail.com <dr...@gmail.com> #7
I think I would preffer option 1.
BTW, I have read that android 4.4 won't include a browser and the device vendors will have to create their own browser usin a webview (or license chrome), that means any browser appart from chrome will have <input type="file"> working.
I've find out that <input type="file"> have a bug on chrome, if you choose documents and then one of the new android 4.4 options ("Recent", "Drive", "Images","Audio", "Downloads", "Internal storage"), it won't be able to pick the file, and the Drive option even make chrome crash
BTW, I have read that android 4.4 won't include a browser and the device vendors will have to create their own browser usin a webview (or license chrome), that means any browser appart from chrome will have <input type="file"> working.
I've find out that <input type="file"> have a bug on chrome, if you choose documents and then one of the new android 4.4 options ("Recent", "Drive", "Images","Audio", "Downloads", "Internal storage"), it won't be able to pick the file, and the Drive option even make chrome crash
ke...@gmail.com <ke...@gmail.com> #8
Great! This new "feature" in 4.4 that is "WorkingAsIntended" will cost us and many other companies a lot of money when we have to give support to all our customers and explain to them that it is no longer possible to upload files in our Android app in which we use WebChromeClient.
Thanks a lot!
Thanks a lot!
ke...@delraybeachlaw.com <ke...@delraybeachlaw.com> #9
[Comment deleted]
li...@gmail.com <li...@gmail.com> #10
This seems like when Apple decided people using the iPhone didn't really need to upload files through the browser. :p
We've just launched an app 9 days ago, which is now basically useless, and are left to explain to the customer that it's google's fault. :p
We've just launched an app 9 days ago, which is now basically useless, and are left to explain to the customer that it's google's fault. :p
an...@gmail.com <an...@gmail.com> #11
We work with numerous companies with dozens of different apps that make use of this feature. I can't for the life of me understand why such a feature would be removed. It lessens the features available within apps targeting the Android OS which makes phones powered by the Android OS less desirable.
I certainly hope something is worked out to address this as this is a huge loss in functionality. I'd be happy with either option #1 or #2 listed earlier.
I certainly hope something is worked out to address this as this is a huge loss in functionality. I'd be happy with either option #1 or #2 listed earlier.
sf...@gmail.com <sf...@gmail.com> #12
I'm suffering, crying for the same issue after spending hours thinking it was my fault. If there is *no* another option (documented or not), why did you remove it? What's the hell is that answer "working as intended"? Gosh.
Just one more thing, :facepalm:
Just one more thing, :facepalm:
st...@gmail.com <st...@gmail.com> #13
I would also prefer option #1
#12 it is your fault, it's not a public API what is hard to understand about it? Software development 101
#12 it is your fault, it's not a public API what is hard to understand about it? Software development 101
an...@gmail.com <an...@gmail.com> #14
[Comment deleted]
de...@gmail.com <de...@gmail.com> #15
#12 It is not your fault. openFileChooser may not be in the public API but this function is used in thousands of Android apps and now all these apps is broken. openFileChooser is the ONLY way to open up a file dialog when using the WebChromeClient.
It is a pity that the webview developers couldn't understand this them self.
It is a pity that the webview developers couldn't understand this them self.
al...@gmail.com <al...@gmail.com> #16
#13, What is hard to understand is that in this day and age, with all the boom in HTML5 hybrid apps, with Titanium and Phonegap on the market, you remove a basic functionality like uploading a file. It's 2013 guys, this is the sort of thing we should be able to take for granted that it works.
th...@gmail.com <th...@gmail.com> #17
I would use option one. It seems to be the cleanest way to handle file-chooser.
sf...@gmail.com <sf...@gmail.com> #18
#13 Just explain how to do a basic freaking standard file upload with the API and I'll happily use it. But there is *no* other way, no alternative... Or, are you suggesting that uploading an image from a mobile is not important and basic feature?
FFS, it's not only an annoyance to programmers, it's almost a betrayal. It s
OTH, even Chrome fails to upload images
http://youtu.be/MzIejKC-7fA
FFS, it's not only an annoyance to programmers, it's almost a betrayal. It s
OTH, even Chrome fails to upload images
ir...@gmail.com <ir...@gmail.com> #19
If you use phonegap isn't very difficult to create a plugin to pick a file
and then upload it with the file transfer and call it with a regular
button.
The native code is almost the same that the existing code on the
openFileChooser, call an intent that will return the file path.
and then upload it with the file transfer and call it with a regular
button.
The native code is almost the same that the existing code on the
openFileChooser, call an intent that will return the file path.
gi...@gmail.com <gi...@gmail.com> #20
You broke file-uploading and released 4.4 without a ready replacement or workaround? O_o
So even if app devs manage to hack around it, they'll have to maintain the hack forever to support phones stuck on 4.4 even after 4.5+ introduces a proper replacement function?
I need a Kitkat bar.
So even if app devs manage to hack around it, they'll have to maintain the hack forever to support phones stuck on 4.4 even after 4.5+ introduces a proper replacement function?
I need a Kitkat bar.
dn...@gmail.com <dn...@gmail.com> #21
Woah,surely Google is working on this issue?? We have a web app in the works that relys heavily on uploading photos via Chrome... Used to work fine until 4.4.
sp...@gmail.com <sp...@gmail.com> #22
Even when uploading a file using Gmail's mobile web version on Chrome it fails on 4.4. So Android 4.4 breaks Gmail on Chrome! I don't really care about the API details, but a modern browser MUST support file upload. Dear Android devs and managers, please take your user's feedback seriously and fix this major bug. Thanks.
jo...@gmail.com <jo...@gmail.com> #23
sp...@gmail.com <sp...@gmail.com> #24
FYI, the relevant Chrome bug seems to be http://crbug.com/278640
Looks like it's been fixed for Chrome 33 (9+ weeks away). Not sure if they used what #23 suggested.
Looks like it's been fixed for Chrome 33 (9+ weeks away). Not sure if they used what #23 suggested.
ri...@gmail.com <ri...@gmail.com> #25
#24, comments #29 and #30 from http://crbug.com/278640 are very insightful. At least they seem decided to fix it for webview aswell.
ra...@gmail.com <ra...@gmail.com> #26
Need this fixed too - solution #19 isn't a clean one, from what I understand is being proposed. It would seem the file upload takes place independently of the POST, so:
1. no session information is passed
2. need a mechanism to tie the uploaded file to the ultimate POST with the corresponding data
3. how long do we store the upload file while waiting for the POST that may not come
4. There is even more trouble when using a load-balancer and multiple web servers.
1. no session information is passed
2. need a mechanism to tie the uploaded file to the ultimate POST with the corresponding data
3. how long do we store the upload file while waiting for the POST that may not come
4. There is even more trouble when using a load-balancer and multiple web servers.
tr...@gmail.com <tr...@gmail.com> #27
#26, phonegap's file transfer uses a HTTP multi-part POST request, so you can pass the other form parameters at the same time you upload the file. (you will need a function to pick and add them to the file transfer options)
Here a simple example manually adding form params:
var options = new FileUploadOptions();
var params = {};
params.value1 = "test";
params.value2 = "param";
options.params = params;
var ft = new FileTransfer();
ft.upload(fileURI, encodeURI("http://some.server.com/upload.php "), win, fail, options);
Here a simple example manually adding form params:
var options = new FileUploadOptions();
var params = {};
params.value1 = "test";
params.value2 = "param";
options.params = params;
var ft = new FileTransfer();
ft.upload(fileURI, encodeURI("
se...@gmail.com <se...@gmail.com> #28
I vote for #2, as it is the simplest method. The web page being viewed should simply "work" without any additional wrapper code. I don't have to intercept events in order to click a hyperlink or a submit button, do I? (I know these events do not interact with the underlying OS the way the file upload does, but the general point stands.)
ro...@gmail.com <ro...@gmail.com> #29
[Comment deleted]
bo...@gmail.com <bo...@gmail.com> #30
[Comment deleted]
pa...@gmail.com <pa...@gmail.com> #31
#27 thanks for the sample. Unfortunately, I'm providing a "raw" app (plain java). Any suggestions/pointers where to look to create the same functionality?
Tnx.
Tnx.
ga...@gmail.com <ga...@gmail.com> #32
My vote for Option 1 .
Please don't just remove undocumented APIs that are widely used . Even though its not recommended to use Undocumented APIs , most of the apps use hell lot of these APIs to add functionality.
Please don't just remove undocumented APIs that are widely used . Even though its not recommended to use Undocumented APIs , most of the apps use hell lot of these APIs to add functionality.
av...@gmail.com <av...@gmail.com> #33
#6 I vote for a combination of both.
I prefer that by default the webview will automatically pop up a UI to choose a file. However we should be able to override the handler method so that would can provide our own functionality or extend the existing functionality.
example:
public void openFileChooser(ValueCallback<Uri> uploadMsg, String acceptType, String capture) {
// here I'm just going to use the default functionality and log it for testing
super.openFileChooser(uploadMsg, acceptType, capture);
Log.e("openFileChooser", "4.1+ - " + acceptType + " - " + capture);
}
I prefer that by default the webview will automatically pop up a UI to choose a file. However we should be able to override the handler method so that would can provide our own functionality or extend the existing functionality.
example:
public void openFileChooser(ValueCallback<Uri> uploadMsg, String acceptType, String capture) {
// here I'm just going to use the default functionality and log it for testing
super.openFileChooser(uploadMsg, acceptType, capture);
Log.e("openFileChooser", "4.1+ - " + acceptType + " - " + capture);
}
[Deleted User] <[Deleted User]> #34
Vote for OPtion 1. Prefer the old undocumented API be documented and supported.
zo...@gmail.com <zo...@gmail.com> #35
Please provide a workaround patch or something in the interim until you get his figured out. This is ridiculous.
vi...@gmail.com <vi...@gmail.com> #36
So many devices updated to 4.4 last night and now the app photo uploader is not working since users cannot select a file. What a HUGE mistake for Android and such a betrayal. "Working as Expected"
Why on earth would you do this to people?
Why on earth would you do this to people?
ro...@gmail.com <ro...@gmail.com> #37
[Comment deleted]
[Deleted User] <[Deleted User]> #38
U need to give us an option to upload files from web apps !!!!
ke...@gmail.com <ke...@gmail.com> #39
[Comment deleted]
[Deleted User] <[Deleted User]> #40
Agreed. We are in a holding pattern on this. What is the workaround or patch?
sp...@gmail.com <sp...@gmail.com> #41
Issue Status: WorkingAsIntended
This is ridiculous.
This is ridiculous.
be...@gmail.com <be...@gmail.com> #42
Working as Intended... Siriously? what a shame.
ch...@gmail.com <ch...@gmail.com> #43
Hey all, Let me start off by saying that the following comment relates to Phonegap/Cordova development.
I've been experiencing this issue as well so I wrote a Cordova FileChooser plugin to a "band-aid" for the time being. Basically, in Android 4.4(KitKat), as mentioned in previous comments, the file dialog is not opened. However the onclick event is still fired on <input type=file> so you can call the FileChooser plugin to open a file dialog and upon selection, you can set a variable that contains the full path to the file. At this point, you can use the FileTransfer plugin to upload to your server and hook into the onprogress event to show progress. This plugin is mainly configured for Android 4.4 so I would recommend to continue to use the native file dialogs for earlier versions of Android. There might be issues with the plugin as I have not fully tested all possible scenarios on many devices, but I have installed it on a Nexus 5 and it worked fine. I hope this helps out some of you.
https://github.com/cdibened/filechooser
I've been experiencing this issue as well so I wrote a Cordova FileChooser plugin to a "band-aid" for the time being. Basically, in Android 4.4(KitKat), as mentioned in previous comments, the file dialog is not opened. However the onclick event is still fired on <input type=file> so you can call the FileChooser plugin to open a file dialog and upon selection, you can set a variable that contains the full path to the file. At this point, you can use the FileTransfer plugin to upload to your server and hook into the onprogress event to show progress. This plugin is mainly configured for Android 4.4 so I would recommend to continue to use the native file dialogs for earlier versions of Android. There might be issues with the plugin as I have not fully tested all possible scenarios on many devices, but I have installed it on a Nexus 5 and it worked fine. I hope this helps out some of you.
be...@gmail.com <be...@gmail.com> #44
Please make it work as it was. My clients are calling me.
Description
System: 4.2.1
Bluetooth audio stutters when wifi is on and connected (transmitting data) making services such as Pandora, google Music, etc not usable over bluetooth audio while connected to wifi. Bluetooth audio stutter was not an issue in previous versions 4.1.2 Problem is only in version 4.2 and 4.2.1