I'm currently developing an application with which a schedule can be retrieved and viewed. To display the schedule I used the TimeRulerView (and BlocksLayout and BlockView) java source files from the Google IO 2011 app because I liked the look and feel. Source code can be found here: https://github.com/underhilllabs/iosched2011 . (Google replaced there one with the code of IO2012).
Since my Galaxy Nexus updated tot Jelly Bean (4.1.1) yesterday the TimeRulerView (and/or one of the others) doesn't get shown anymore.
The weird thing is that they are actually still there, but there not visible. I can see a scrollbar of the length the timeruler normally has. Also when I normally click on an block in the view I get a little pop-up, and this still happens when not seeing the timeruler or a block.
I tested the original IO2011 app on my JB GN but nothing is visible there either, so the problem lies within (one of) the view(s) or the way JellyBean is rendering the view(s) (project butter maybe?).
See here ( https://dl.dropbox.com/u/7102660/TimeRulerView_JellyBean_problem.zip ) for screenshots on ICS (app working), JB (app not working) and the GoogleIO2011 app.
Could this be something to do with Hardware acceleration? I just recently ran into an issue on couple phones with ICS, but not all phones/devices were affected. Adding the hardwareAccelerated tag to my manifest didn't fix the issue either, and I had to define it on specific views that I did not want to be hardware accelerate. My solution used android:layerType="software" in my xml layouts and setLayerType(LAYER_TYPE_SOFTWARE, null) in the java code.
EDIT: Testing this more, it didn't fix my issue using setLayerType on Jelly Bean. Setting the layer type to software on ICS did fix my issue. The only way I could make the views show up was setting the whole application or specific activity to android:hardwareAccelerated="false".
Thanks to Chris answer I played around with hardware acceleration settings. I use the iosched2011 code as well and only had to remove the line android:layerType="software" from my BlocksLayout View inside the block_content.xml file .
Related
Background
I have a live wallpaper that uses the relatively new API (from Android 8.1 - API 26) to request the OS to use customized colors:
https://developer.android.com/reference/android/service/wallpaper/WallpaperService.Engine.html#notifyColorsChanged()
https://developer.android.com/reference/android/service/wallpaper/WallpaperService.Engine#onComputeColors()
The problem
On Android 8.1 and even on Android P DP1, all worked fine with these functions, as they did what normal wallpaper do with the colors, affecting the notification drawer if the color that was chosen is dark enough. Here's a comparison between choosing a non-dark color and choosing a dark color background:
Thing is, on Android P beta (DP2), even though this function get called, it doesn't do anything, ever.
To test it on your own, you can try the full project I've published here.
What I've found
I thought that maybe the API has changed, so I've tried to find which functions are available, but I couldn't see anything that's new.
I've tried to use various ways to return the customized colors:
a. WallpaperColors(Color.valueOf(0xff000000.toInt()), Color.valueOf(0xff000000.toInt()), Color.valueOf(0xff000000.toInt()))
b. WallpaperColors.fromDrawable(ColorDrawable(0xff000000.toInt()))
c. WallpaperColors.fromDrawable(BitmapDrawable(completelyBlackBitmap))
d. WallpaperColors.fromBitmap(completelyBlackBitmap)
Sadly none worked (fromBitmap is the one that works well on Android 8.1).
Seeing this, I've re-checked that my code is ok, and noticed that the built in live wallpaper works fine, and that selecting a solid black wallpaper (instead of live wallpaper) also affected the UI of the OS.
Seeing that it works with built in apps, I've reported to Google about this issue, only to find out that they don't understand what I'm talking about, and each time I've tried to tell them they've misunderstood it differently:
https://issuetracker.google.com/issues/79404938
https://issuetracker.google.com/issues/79665215
https://issuetracker.google.com/issues/80029770
I wanted to make sure it's not an issue with just my app, but with others too, so I've tested Muzei live wallpaper app, which is actually made by one of Google's own developers. The issue indeed occurs there too, while working fine on Android 8.1.
I was just curious, and wanted to check if the issue could occur if I've moved Muzei to be a system app, but after doing so, I've seen the issue still exists.
The questions
How come it doesn't work anymore?
Is there a workaround/fix for this?
Why does it work fine for built in apps and for normal wallpapers, but not for third party apps? I don't think their code is any difference.
OK, Google confirmed it's a bug, which will be fixed on later version:
The development team has fixed the issue that you have reported and it
will be available in a future build.
And, it works fine now on DP4 (beta 3) of Android P.
I'm using a barcode scanner library wich uses a camera layout, the usual. I tried the library on three devices and it looks fine in all of them.
But in the fourth device, it looks like this.
I uploaded pictures instead screenshots because, when you make one, the bug doesn't appears on it. It just looks normal. This makes me think about some kind of GPU/Android bug or something like that, but I really don't know where this is coming from and how to fix it.
By the way, the devices I used testing are: Nexus 5 (6.0.1), Galaxy Young (4.1.2) and Doogee DG685 (4.2.2). In all of them the layout is perfectly showed. The bug only appears on a HoneyWell E70 (4.0.3).
Author has explained to me that it's caused by using SurfaceView instead of SurfaceTexture.
The library has a XML attribute to fix it:
app:zxing_use_texture_view="true"
But it's not documented. In the next release this option will be true by default.
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.
In rare situations our application goes into a state where no letters are displayed. Screenshots are attached to demonstrate this. On the first is the application in normal state, on the second with letters disappeared (http://pic.pschstavebni.cz/limigo.png). It seems that all the TextViews (updated in code) does’nt display any text. This happens rarely and we can’t reproduce it in test environment. For most users, the application works fine, for few of the users this state sometimes occurs. After a device restart the application works normally. Does anyone know what could cause this problem?
Users have Samsung Note 8 tablets. Layout is done using fragments in v4 support library.
All TextViews have default value in xml layout. I checked code for uncaught exceptions and OutOfMemory problems, but without success.
Make sure that the elements on the XML layout have a good alignment.
The issue has been resolved after upgrading to a newer version of android.
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.