Recently my application received quite a lot comments that "it's not working" on Android Ice Cream Sandwich with CM9. I'm not able to reproduce the error on the emulator running Android 4.0 and thanks to the way android market works there's no way I can't contact those people to ask about the details.
Luckily, one crash error report caught my eye. I'm using Canvas.clipPath to draw rounded corners... and looks like some phones are throwing UnsupportedOperationException when trying to use that function. Quick look at Google reveals that it seems to be a problem when using hardware acceleration in Android 4.0 - so that's the potential reason of received comments.
The question is - what's going on? Weren't applications hardware accelerated in previous android versions? Why such common function isn't supported? What's the workaround?
Example usage of Canvas.clipPath can be found in my other post. Check the accepted answer here: Android rounded corners in ListView
Thanks in advance
In ICS, hardware acceleration was turned on by default. Until 4.0, the default was that hardware acceleration was off.
Hardware acceleration does not support clipPath (and a few other operations, see more here http://android-developers.blogspot.com/2011/03/android-30-hardware-acceleration.html)
I am facing the same issue. As a quick fix I will turn off acceleration for the entire application, and later I will rewrite the code not to use clipPath
You can turn off hardware acceleration only on the specific view that is causing problems. Check out my answer here: https://stackoverflow.com/a/14054331/596708
Related
Since a while ago I started having some artifacts on some android devices. I have checked build settings, I was disabling code stripping and setting all options to the default ones - nothing worked out.
This visual interference (see screenshot) happens at least in Note II and HTC One Mini/2. Nexus 5 exhibited very minor interferences.
Any help would be highly appreciated!
Picture here
Well, that was quite obvious, I just needed to turn on my brain, lol.
So, if you're having issues with rendering like I was - try to check your main camera.
And especially be careful with Clear Flags property. Personally, I have faced with a situation when some of my background layers (which have SpriteRenderers on) were switching their alpha values. At that point camera would "see" through the layers. And that is the problem if you have "Don't Clear" value in "Clear Flags" property.
Hope it helps.
which Unity version are you using? Can you make sure to use ETC1 compression (+alpha if needed) and try again on those devices?
My app runs with many devices but 2 users have send me simular images as below.
As far as I know the behaviour is only seen on Android 4.2.2 (Samsung S4).
On the full HD screen there seem to be 3 compressed tiles of 160x600 pixels.
I have tried an AVD with full HD screen but that fails to start.
On 4.03 devices I don't see this. I don't use tiles.
Does anybody have a hint what or where this goes wrong ?
This looks like a possible bug in the Android platform on Samsung's S4 devices with that particular Android version. My experience tells me that it's a very real possibility. It could also be that you do something wrong in your app that only causes actual problems on that version (and maybe even only on that device), but there is no indication of that from what you tell. Android 4.2.2 should be backwards compatible with 4.0.3, so in general it should work on the later version too, of course.
I would advice you (or anyone in the same situation) to try it out on other devices with the same Android version if possible. Also, double check that you're not violating anything in the Android API documentation.
Please add more info about what you're doing and how if you need more detailed answers. I guess you've probably found a solution or workaround by now, but still adding my answer here.
I have a widget that makes use of a new feature that, according to the infinite wisdom of the intarwebs, is stock in Android 4.0 (Ice Cream Sandwich). Conveniently, my phone is just that.
This widget inverts the screen colors for the phone. Not just an app; the screen in its entirety.
I started playing around with an amazing app called Tasker the other day that can do some crazy-powerful things; including run scripts, send commands to the phone, etc.
I'm trying to figure out where in the world this inversion lives so I can tap into it myself via Tasker, but I'm falling short everywhere. The Android API documentation is Greek to me, and Google seems to only ever want to point me to people talking about how great the feature is.
Any ideas as to where I can find this feature/function/action/whatever in a programmatic sense?
Thanks much in advance! Any help will be most appreciated.
I've searched and the only thing I found is when it's available on custom roms/kernels.
I don't think it's available for stock roms.
I found that when I set my targetSDK to 15 that I get the color wheel in this app not rendering the colors correctly as per the issue I raised below.
http://code.google.com/p/superdry-colorpicker/issues/detail?id=2
Having not heard back from the developer yet I want to try and fix it myself, but I am completely lost when I look at the code.
Is someone albe to tell me what the issue is or point me in the right direction?
Thanks.
Probably due to ICS hardware acceleration that gets enabled when you set it to that target version. Try to disable HW acceleration and see if that works for your app (in your manifest)
I'm trying to make some of my applications available on Android 4.0 (Ice Cream Sandwich) devices. It would be helpful to know the different things to look for, as sort of a checklist.
What are the generic steps necessary to make an application available and functional on an Ice Cream Sandwich device? I'm not looking for every single potential API change to make, but any detail would be appreciated.
One thing I have encountered relating to usability is that if you have a fullscreen activity, to allow some way to exit it or go back since phones might not have hardware keys to send the back event. Basically, never assume that the user has hardware keys available.
Google also recently released a design guide for ICS available at http://developer.android.com/design/index.html
Well, as Blundell said, it should work without any problems. I have however, found one quirk while running ICS in the emulator with my apps (maybe this applied to Honeycomb as well, no idea).
Here it is - if you have an app widget, and you don't provide the android:previewImage attribute in the appwidget-provider configuration, your widget will not be visible in the "Widgets" tab. You can use an app that comes with the ICS emulator (Widget Preview) to generate this preview image.