We have an HTML5-base app that's running in PhoneGap, using (mostly) jQuery for the components. Fairly regularly, the UI will be changed in javascirpt, but not completely render correctly. You kind of need to nudge it with another touch event, which causes it to "remember" to redraw everything. I suspect its some attempt to optimize the draw, but it forgets to update other parts of the screen that were changed.
I'm going to start modifying different css settings in the hope that it turns out to be some kind of simple bug, but I'm surprised that this isn't reported more widely (which makes me think this is due to a "magic combo" of css attributes).
So far the vast majority of testing has been on ICS. I don't have a 2.x device handy right now, but will try that tomorrow. My phone updated to Jelly Bean, so I'll try that and see if anything is different.
Will try to post a screenshot later.
Thanks in advance.
UPDATE
This works fine in Jelly Bean. I did a search in the public Android bug DB but nothing turned up. I'll have to dig out another phone with ICS on it and try different CSS settings and see if it goes away.
Related
I understand CodeMirror has issues on mobile and behavior varies with extensions in use.
However, for me it seems pretty much unusable everywhere I encounter it on Android. Have a look at Kotlin Koans and try the Backspace key. Amongst other things, I get gobbledygock and a bunch of newlines.
I did not find a single way around this. Tried two devices (OnePlus 3T and Pixel C) running Android 7 and 8 using on-screen keyboards or bluetooth physical ones. The results are pretty much the same.
This seems pretty odd and I am surprised nobody (Google?) is stepping in to fix it.
I'd like to use an Android device for basic (CodeMirror-based) coding, and I'd very much appreciate a suggestion to get around this annoyance. :)
Thanks
Code Editor inserts a new line above current line on every keypress
Android native app using WebView, backspace doesn't work properly
I'm intermittently observing strange graphics artefacts in my app, as shown below. This is a screengrab from a Samsung Galaxy S3. I have only observed it on this particular phone. I have run the app on a Samsung Galaxy Tab S4 and an HTC One, and never observed this issue on either - although admittedly I do mainly use the S3 for development.
I considered that the issue might be some sort of concurrency clash in drawing to the Canvas (I'm using the basic Android rendering methods, no OpenGL or anything), since I can clearly recognise the repeating units of other UI elements, so I synchronized all the code which draws to or interacts with the Canvas and I'm still observing it happen.
It does clear itself up after around 30-90 seconds, which may be due to a regular scheduled memory cleanup operation it performs - so perhaps this is a manifestation of low available mem?
If I had enough rep I would stick a pretty big bounty on this. Any help appreciated. Hopefully someone recognises this particular problem.
Apply hardware layers:
setLayerType(View.LAYER_TYPE_HARDWARE, null);
This bug only occurs on my Nexus 5 and my Nexus 7 running Lollipop.
EDIT
This bug also occurs in the new Inbox app by Google, when I'm going into Inbox > Settings > Notifications > any item and go back...
/EDIT
compileSdkVersion 21
buildToolsVersion 21.1.1
compile 'com.android.support:appcompat-v7:21.0.2'
I'm having a GalleryActivity that shows multiple images, once per page (inside a ViewPager. When I hit the back button, sometimes the Android's SystemUI have glitches.
Normal view
Glitched view
See how the views repeats themselves, and inside the system itself?
A simple touch event brings back the normal SystemUI views.
What is going on?
Might be similar to:
Android 5 screen glitch/static with Google Maps Fragment inside a Viewpager
Android Lollipop Activity Screen corrupted
Setting android:hardwareAccelerated="false" is a kind of extreme solution, as graphical performance is likely to be very bad.
If you can pinpoint the view that is misbehaving and causing this issue, a better fix would be to switch it to software rendering instead, via setLayerType(), e.g.
view.setLayerType(View.LAYER_TYPE_SOFTWARE, null);
Funny thing is, I haven't experienced any rendering glitches with Lollipop so far, but we did see them in KITKAT (as mentioned in this question), and only when WebViews are present on the screen.
I would recommend experimenting with toggling this on different views until the problem is isolated (especially if it's easy to reproduce).
So far, every occurence of this issue has been related to WebViews (or components that use WebView, such as AdMob). According to the AOSP Issue Tracker the problem is fixed in Android 5.0, but it doesn't seem to be the case.
I've seen UI glitches with Lollipop, though different than yours. The only workaround I found was disabling hardware acceleration:
android:hardwareAccelerated="false"
at the Activity or Application level. If this resolves your glitches, make sure to report this to Google as this would indicate a bug in the platform. There is already at least one open report with them already.
I certainly wouldn't want to deploy an application with this setting, it's really only intended to answer the WHY and help prove that it's not a bug in your code.
Hope this helps!
EDIT 12/10/2014:
#matiash offered a much more precise answer than this "sledgehammer" suggestion. I was seeing drawing glitches mostly on the ActionBar in a multi-tab app with ViewPager, and always on tabs/pages without any WebView at all. However, one of my tabs/fragments does have an embedded WebView, and when setting it to software rendering, my glitches appear to have gone away. I'm not at all uncomfortable putting the workaround suggested by #matiash in a shipping app...though it still points to some underlying issue in the platform.
I have also witnessed this problem in my own app.
Any Android devs ever experience this kind of visual static? (see picture)
Not only did I get that kind of visual static, but also repeated drawing. Only witnessed it on Nexus 5 with 5.0 when developing with api 21 and support library 21.0.+.
For me its not very reproducible. It will happen repeatedly during one session of use, but the next day I won't be able to reproduce it.
I am not using any WebViews (accept maybe via admob). I am using ViewPagers with fragments. I am also using DragSortList and first started seeing the issue in Activities that used it.
https://github.com/bauerca/drag-sort-listview
How reproducible is it for you guys?
have you tried to set android:fitsSystemWindows="true" in your Fragment layout? this will make sure the layout is below the statusBar, im not really sure about the navigation buttons but i guess this should work for it too.
Call request layout on DecorView after rendering:
getActivity().getWindow().getDecorView().requestLayout();
I call it using postDelay() in WebViewClient.onPageFinished(). It's not a perfect solution (just a workaround) but maybe better way like LAYER_TYPE_SOFTWARE.
.........go to settings and then developer options(if they are not visible... go to about phone then click on build number 7-10 times and developer mode will be on) and there scroll down and untick 'show layout bounds' and you are done. its simple and easy.
We're developing a custom Android application built for a specific Android -- formerly the Samsung Galaxy Tab 2 -- and I was pretty happy with the way it looked.
However, we've changed phones to the Nexus 7, and now a Text View that used to look fine blinks rapidly -- it's seizure inducing. My application updates the text a few times a second, but that's not new and we never had this problem with the Samsung.
Has anybody experienced something similar, or otherwise have a suggestion?? My original suspicion that the Samsung had more processor power is, I'm pretty sure, incorrect. Should I look into some of the Nexus' configuration details concerning rendering the GPU??
It's going to be annoying if have to get rid of this software feature, but I might have to if I can't improve the look.
It's not a great answer, but it does work for me if I set up my code to only update the text view every other trip through the draw loop. If anyone else has a different suggestion I'd certainly prefer to try something else, but this at least works.
The Android Browser can't scroll inner divs. That means using SlickGrid with its default configuration is impossible.
Fortunately, SlickGrid has an autoHeight argument that makes it not use inner scrollable content, so it works on the android. Unfortunately, when autoHeight is enabled, onViewportChanged gets called once to span the entire viewport and is never called again, so it attempts to load all the data at once. I'm lazy-loading and displaying so much remote data that if you try and load it all at once it crashes mobile devices, so that's a no go.
If SlickGrid were smart enough to know what's on the screen even if autoHeight is enabled, that would solve my problem. I'd love it if that was a feature in core, since that would solve many problems on the desktop as well as on Android devices.
I also tried using iScroll 4 to get around the Android limitation. Unfortunately, it doesn't trigger onViewportChanged at all when I use iScroll.
I will probably have to solve this by ditching or modifying onViewportChanged to handle my own scrolling events. I was wondering if there is an existing solution for this though.
I ended up writing my own version of slickgrid for this purpose. Also, this will become irrelevant when Google Chrome becomes the default browser, as it actually has decent support for scrolling.
I would not recommend using SlickGrid for apps/pages targeting mobile devices. The grid was not developed with mobile devices in mind. They require a completely different approach optimized for that particular use case.