Fixed
Status Update
Comments
xa...@android.com <xa...@android.com> #2
unfortunately, openFileChooser is not a public API. We are working on a public API in future releases of Android.
fr...@google.com <fr...@google.com> #3
ok :(
ph...@gmail.com <ph...@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?
ph...@gmail.com <ph...@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?
ph...@gmail.com <ph...@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
ph...@gmail.com <ph...@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
ph...@gmail.com <ph...@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!
ph...@gmail.com <ph...@gmail.com> #9
[Comment deleted]
ma...@gmail.com <ma...@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
fc...@gmail.com <fc...@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.
jb...@google.com <jb...@google.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:
Description
OS version: OSX 10.10
1. Went to
2. Downloaded android-studio-ide-135.1626825-mac.zip
3. Extracted 'Android Studio' from this zip and dragged it into Applications folder
4. After creating a sample app, tried to launch the default 'Nexus S API 21' AVD
EXPECTED:
- Emulator launches
ACTUAL:
- Error message in console:
/Users/archersa/Library/Android/sdk/tools/emulator -avd Nexus_S_API_21 -netspeed full -netdelay none
emulator: ERROR: x86 emulation currently requires hardware acceleration!
Please ensure Intel HAXM is properly installed and usable.
CPU acceleration status: HAX is not installed on this machine (/dev/HAX is missing).
5. Launched Android SDK Manager
6. Manually installed HAXM 5.2
EXPECTED:
- Emulator now runs
ACTUAL:
- Error message in console:
/Users/archersa/Library/Android/sdk/tools/emulator -avd Nexus_S_API_21 -netspeed full -netdelay none
emulator: ERROR: x86 emulation currently requires hardware acceleration!
Please ensure Intel HAXM is properly installed and usable.
CPU acceleration status: HAX is not installed on this machine (/dev/HAX is missing).