I try to run an embedded web in Android, but it crashes when using Android 4.3 (Nexus 4). I run the app and the first webview appears correctly, but when I touch the textbox and the keyboard appears, the view gets frozen just on the top part of the keyboard (where the text predictor is located in case it's active).
This problem only appeared when using 4.3, not with the previous versions.
I've been trying to fix the bug as it says in this issue, but the solutions they give don't resolve my case: https://code.google.com/p/android/issues/detail?id=42518&q=webview&colspec=ID%20Type%20Status%20Owner%20Summary%20Stars
I would love if somebody have been through this problem, because we don't know what to do to fix it...
After more than one year without trying the app, it is working now. The device now is running Android Lollipop, so I guess that probably the WebView has some improvement that avoids the bug.
Related
App Crash on Android Tablet and when ever tried to open it again it open a blank black screen there after. This is happening with android debug build.I have tried to replicate the issue on simulator and it didn't happen. Please let me know if any clues about this issue. Is it something related to inefficient memory usage or something else. Is there any tool I can use to narrow down this issue. This is not happening on IOS devices and even Android Phones.
While developing an app wich uses phonegap, angular touch and jquery we stumble in this bug on some android devices.
When touch and move over an non scrollable object the screen goes blank.
When scrooling the body the screen comes back to life.
All the elements stays in dom and still firing events and so.
When using developer tools we still can see the elements.
http://youtu.be/NdTerKi08WE
Has any one saw this bug before?
EDIT
Im using phongegap build so i dont have access to java files.
This problem is only on Android 5 phones.
EDIT 2
Same problem on device chrome browser so its probably not an phone gap problem.
The problem was an issue regard to rtl in the new chromium.
The workaround is to add the "rtl" to css on document ready.
I am trying to write an application with Mono for Android. In an attempt to do this, I'm using the default template in monodevelop. I can successfully compile and run the application. When I run the application, it looks similar to the one shown here: http://docs.xamarin.com/android/getting_started/hello_world
There are two oddities in my version though:
The button is red
I can't seem to actually click the button. When I use my computers mouse, it acts like it won't click the button. This is not limited to the application either. If I try to click the home or search button in the emulator itself, I noticed that nothing happens either. Its like the emulator is not responding to my mouse.
As someone new to working with Android, can someone please tell me what I'm doing wrong? I'm using MAC OS X with Lion installed. I'm assuming that I have the SDK and Java SDK installed properly considering the app compiles and when I press "play" I can load the app in the emulator. I just can't figure out why I can't actually click the button. So bizarre.
Any ideas?
The title of this question is pretty misleading, since you're saying that the emulator is not very responsive even outside the Mono for Android application. The problem here is with the emulator itself. The one thing I would recommend trying with respect to Mono for Android is to try starting the application without debugging, as debugging will add extra overhead to running the app.
The Android emulator is notoriously slow, since it is fully emulating the ARM instruction set in software. That said, there are certain things you can do in order to squeeze some more speed out of it. One thing that I've seen make a big difference is to decrease the screen size of the emulator image. Setting this to a small screen size (such as QVGA) can make a big difference. You can manage these settings through Android's AVD Manager.
I have a very simple Android app. It is one Activity with Text and Buttons, and as you click on the buttons (onTouch events), they become invisible and the text changes.
This works fine for Android 3 and Android 2.3.3 simulators, but when I use the BlackBerry nature in Eclipse to send the app to a BlackBerry playbook simulator, funny things happen. As I click on the buttons they go invisible, but other buttons change too.
Buttons that were only ever visible, stay visible. Some Buttons that were invisible, become visible. Some buttons that had become visible earlier, return to being invisible.
It feels like a redraw problem, or some strange caching on the button state.
Anybody got any ideas? Wild guess excepted ...
Get a playbook or wait until RIM updates their broken simulator.
I converted an app for the playbook and the code was running fine on the simulator. It's a very simple app too, like a binary calculator. A couple of toggleButtons, Buttons and a TextView.
The app had visual issues, similar to yours. Buttons disappeared. Buttons were highlighted when I pressed buttons around them. ToggleButtons didn't change state. And much much more.
Since I don't have a playbook I couldn't test it on a real device. I tried layout changes, code changes and tried different settings. But nothing helped, those issues stayed.
After some reading in their forum I came to the conclusion that this might be an issue with the simulator.
So I submitted the app to the AppWorld 5 days ago. It got approved today.
So there is a chance that your app is alright, and the problem is the simulator.
I have this browser launching application which didn't have any problem till now: when it is being tested on Samsung Galaxy 10.1 (Model Number: GT-P7510) with Android 3.1 Honeycomb.
The issue is this: whenever I tap on a text box, the whole screen will flash across a black screen for a moment and revert back to normal. It starts flickering/blinking the black screen when I leave a focus on any text box as well.
Currently, I've no idea what is causing this issue as I've tested this application on several devices e.g. Samsung Galaxy S, Samsung Galaxy Tab 7-inch with previous version of OS from 2.1 to 2.3.
Anyone who has any clue as to what is going on whether be it a compatibility issue with the app or a change in function in honeycomb 3.1 or the device itself, please share your information and enlighten me on this matter please. Any kind of help is greatly appreciated!
Thanks
I'm sorry that this is not a solution, but I think I can shed some light on the problem.
We have recently been testing a functional jQuery Mobile HTML5 app wrapped with PhoneGap Android 2.x phones to the Galaxy tab 10.1. We have seen something very similar, with the exception that we have defined a splash screen for our app. What we see is that when an input field is given focus, the screen flashes up the splash screen momentarily. Very annoying! To verify if this is the same problem, define a splash screen for your PhoneGap app and see if the screen flahes your image instead of a black background. Knowing something about what's going on with PhoneGap and the Android WebView, this is my best estimation of what is happening: PhoneGap loads the main App activity with a black background and displays the splash screen (if defined) in that initial window. PhoneGap then starts the WebView and opens it on top of the main Window. When a field is selected, the Android invalidates the component wach time it updates it based on a focus event or keypress, or whatever, and Android redraws everything. So it redraws the main window behind the WebView and then redraws the WebView with the HTML page content on top of it. Since the device is not properly double-buffered, you see all of this redrawing in all its ugly glory right in front of your eyes.
We have seen serious glitches with Android web forms on some Android 2.x phones we have tested, and this looks like yet another glitch, but this time on the Galaxy Tab running Honeycomb (3.0).
We have attempted to use CSS -webkit-backface-visibility to resolve issues on some phones when experiencing flicker in the past - but this has caused serious rendering issues in HTML forms. Be warned! In theory this should be a viable fix to introduce some double-buffering into the mix, but in our experience it causes more problems than it solves.
I am not confident that this can be resolved, except by an Android software update from Google/Samsung.