I am developing on Android with cross-platform coding which uses the webkit feature for printing out the GUI.
I have noticed that my app compiles and looks good on several android phones but on the S4 there are serious webkit issues. No errors are thrown but the canvas objects are not being displayed properly and the problems seem to be completely random. The same code will display different types of rendering problems during each refresh.
I have searched the net and it appears to be a specific problem for the S4.
Are there any known solutions to this problem? Or are any webkit based apps pretty much useless on the S4? Specifically I am developing using Phonegap and debugging using Eclipse - testing is being done on an actual device, not virtual.
I have had some minor success by turning off hardware acceleration but the rendering problems are still so bad that the app would not be useable on the S4.
Thanks.
Related
Will all apps have to be updated to take advantage of GPU UI rendering, or will Android be able to render all apps via the GPU natively? I desperately hope every app won't require an update to stop using the CPU to render the app's UI with, but I'm afraid that is probably the case. Anyone know for sure?
Roland Deschain said:
Will all apps have to be updated to take advantage of GPU UI rendering, or will Android be able to render all apps via the GPU natively? I desperately hope every app won't require an update to stop using the CPU to render the app's UI with, but I'm afraid that is probably the case. Anyone know for sure?
Click to expand...
Click to collapse
If you look at honeycomb you have to enable hardware rendering in the manifest. But that was because some things don't work properly. Hopefully they've either fixed it so all hardware rendering works, or added a new manifest option to turn off hw instead of turning it on.
Ok; thanks.
HomerSp said:
If you look at honeycomb you have to enable hardware rendering in the manifest. But that was because some things don't work properly. Hopefully they've either fixed it so all hardware rendering works, or added a new manifest option to turn off hw instead of turning it on.
Click to expand...
Click to collapse
This is true, but just wanted to add a bit from what I understand the reason they put it so you had to manually enable it in your app was because HW acceleration caused slowdows on certain types of 2D drawing, especially lines. So this may not change for ICS. If the HW for 3D stuff is still designed around triangles, then the 2d stuff would still be slow.
Basically I think they wanted people to manually enable it to be aware of how and when to use it. If Android were to move to a 3D interface, then there would be more use for it on UI components.
Anyways this is basically what the Google engineers were telling me at the Developer Labs a couple weeks ago. (This is as far as I understood it, I'm no expert in this area, so I may be getting some bits wrong).
Basically this may not really be a "bug" that will ever get "fixed" so to speak. It may be intentional to not use 3d rending when lower-power, faster, 2d rendering would do.
I installed Evil_Alex_Unleashed ver 1.0 on my 501 and it mostly works great. I do however have problems with OpenGL:
Some Games freeze (Ritide GP, Beach Buggy)
Some Games just crash (Clouds & Sheep, Google Maps)
Rebooting the tablet often fixes the problem, but only for a limited time.
I can PM a logcat of such a crash, but don't want to post it (may contain other information).
The developers of Clouds & Sheep reckon that in their case OpenGL is crashing, potentially due to a driver problem. Can't say with certainty whether the other apps also crash because of OpenGL or due to some other problem, but it does seem likely. I did not have those problems with HC.
Does anybody else have those problems (Evil_Alex or stock ICS)? Is there a fix?
This is a well known problem. AFAIK it is caused by a memory leak in OpenGLES in graphic driver for ICS/JB. This also breaks Chrome browser after some time.
follow-up questions
yaworski said:
This is a well known problem. AFAIK it is caused by a memory leak in OpenGLES in graphic driver for ICS/JB. This also breaks Chrome browser after some time.
Click to expand...
Click to collapse
Thanks. Some follow-up questions:
Is this a problem specific to Evil_Alex, the Iconia 501, or any ICS/JB device?
Where can I find more info on this problem?
Is there a work-around or fix for the problem (e.g. give the driver more memory, use a different driver, ...)?
Does this problem affect everybody, or just some tablets?
Cheers,
Carsten
@ich23: I'm not sure but it seems it affects at least all ICS/JB based firmwares for Tegra2 based Acer tablets. I don't know if other Tegra2 devices are affected too as I don't follow threads on forums for those devices.
http://www.onskreen.com/cornerstone/
would be fantastic to have this capability on the Nexus 10. but nobody ever seems to work with it. any particular reason why?
>http://www.onskreen.com/cornerstone
>but nobody ever seems to work with it. any particular reason why?
No interest. Probably why it went open-source (it wasn't originally). My guess is that pushing bits for 3 concurrent apps would require more than a simple launcher swap, ie low-level optimization, and the OnSkreen peeps weren't up to it. Something like this would need to be done by Google.
The reason for lack of interest is obvious. Up till recently, Android's focus has been on phones, and muti-windowing is irrelevant on those. Even now, phone is Android's primary focus given its market size. The tablet's unique traits are still mainly left unexplored. Witness that multi-user acct--an arguably essential feature--was implemented only now in the latest 4.2 release.
IMO, the 3-pane fixed layout looks clunky (and ugly, but aesthetics can change). The need to configure each panel is clumsy as well, as opposed to, say, Win8's split-window scheme where one can config each window on-the-fly. Win8 does have the advantage of edge-swiping, which gives it an extra layer of configurability.
The underlying weakness of both this and Win8's fixed dual-windows layout is the Achilles' heel of touch UI (relative to mouse UI)--the lack of a precise pointer that would allow easy manipulation of multiple, possibly overlapping windows. Pen input is an option, but is likely not the answer.
The issue is resolvable, and for mobile OS'es to take the next step up from phone displays to larger form-factors, it will need to be resolved. Take this and Win8's split-screen as the first baby steps.
e.mote said:
>http://www.onskreen.com/cornerstone
>but nobody ever seems to work with it. any particular reason why?
No interest. Probably why it went open-source (it wasn't originally). My guess is that pushing bits for 3 concurrent apps would require more than a simple launcher swap, ie low-level optimization, and the OnSkreen peeps weren't up to it. Something like this would need to be done by Google.
The reason for lack of interest is obvious. Up till recently, Android's focus has been on phones, and muti-windowing is irrelevant on those. Even now, phone is Android's primary focus given its market size. The tablet's unique traits are still mainly left unexplored. Witness that multi-user acct--an arguably essential feature--was implemented only now in the latest 4.2 release.
IMO, the 3-pane fixed layout looks clunky (and ugly, but aesthetics can change). The need to configure each panel is clumsy as well, as opposed to, say, Win8's split-window scheme where one can config each window on-the-fly. Win8 does have the advantage of edge-swiping, which gives it an extra layer of configurability.
The underlying weakness of both this and Win8's fixed dual-windows layout is the Achilles' heel of touch UI (relative to mouse UI)--the lack of a precise pointer that would allow easy manipulation of multiple, possibly overlapping windows. Pen input is an option, but is likely not the answer.
The issue is resolvable, and for mobile OS'es to take the next step up from phone displays to larger form-factors, it will need to be resolved. Take this and Win8's split-screen as the first baby steps.
Click to expand...
Click to collapse
It doesnt help that when Cyanogenmod was considering baking Cornerstone into their builds, Google threatened to blacklist their roms from accessing the market/Google Play if they didnt change their mind due to potential compatibility issues... since then its seemed nobody wanted to risk touching it. Too bad, while I agree three panes were clunky, two panes like WinRT does could have been quite nice.
>It doesnt help that when Cyanogenmod was considering baking Cornerstone into their builds, Google threatened to blacklist their roms from accessing the market/Google Play if they didnt change their mind due to potential compatibility issues...
Didn't know that, but it makes sense. Fixed layouts like this (and Win8's) rely on specific criteria to work, ie a widescreen aspect in landscape mode. While MS can dictate the form-factor for Win devices, Android devices come in varying shapes, and fixed layouts are doomed to fail.
For multi-windowing to work, layout needs to be adjustable, as well as dynamically adjusts to both portrait and landscape orientations. Secondly, multi-window needs to be supported by all apps, not just some (like in Samsung's implementation). This means it needs to be in the OS, not an add-on.
Samsung's multi-window scheme is a more elaborate version, and is probably a precursor of what we'll see in Android. Note however that the Galaxy Note 10.1 in this example has pen input support, which obviates the Fat Finger syndrome. A platform-wide scheme will need to accommodate "imprecise" adjustments, which IMO will likely mean a snap-to-grid windowing system.
Edit: I added video for the 5.5" Galaxy Note 2 below. Even though the Note 2 supports S-Pen, apparently the cascading/adjustable window portion was dropped, and only the adjustable dual-window remains.
This makes sense for screen sizes 7" or smaller, and would be an improvement over Metro's current scheme. But the missing piece is for larger sizes WITHOUT the precision (and fiddliness) of pen input. This matters especially when tablets gain the use of external displays via Miracast. Again, my opinion is that cascading/overlapping windowing is still doable for Sausage Styluses, rather than just tiled, but snap-to-grid would be needed.
I've got a question for all you mobile developers. There are so many different mobile devices out there. What solutions, techniques or processes are you following or doing to make sure you have a high confidence that your app works on these different devices?
When building your apk , you check the versions you want to support, but there is always some limit, memory, screen size, etc.
http://developer.android.com/training/basics/supporting-devices/index.html
Thank for the link. I was wondering from an experience perspective, what elements are to look out for when testing from device to device (e.g. screen size, resolution, layout etc.)
jralabs said:
Thank for the link. I was wondering from an experience perspective, what elements are to look out for when testing from device to device (e.g. screen size, resolution, layout etc.)
Click to expand...
Click to collapse
The main issues I've seen caused by fragmentation are (in no particular order): the assumption of a portrait screen orientation (i.e. that you won't wind up with apps running in/on devices with square or landscape default orientations), assumption of a certain phone speed/heap size (pretty obvious when lots of image/drawable processing is involved and an app runs badly on an early device), assumption of at least a certain number of dps from width/height (some layouts might have overlapping elements/hidden elements on phones that have a small physical area), using the "device default" themes (some manufacturers -- wrongfully -- change these themes to make OEM apps work better, but then mess up other apps that rely on these), and (this deserves its own special spot) Samsung compatibility quirks. At least in my experience, Samsung devices tend to way more issues with fragmentation as Samsung themes/tweaks Android so heavily it occasionally breaks expected Android behavior.
Hi there
Can you help me confirm that my phone have broken hardware or something?
I have try 6 different ROM's 5.0 and 5.1. Custom and official. Did all wipes, factory restets etc. Everywhere I had constant crashes in some application like Viber, Firefox, Moonreader, AnkiDroid and Weatherbomb.
Some ROM's had constant crashes in google account setup and TouchWiz.
I have S5 with 5.0 official and all these apps works fine there.
All applications crash traces have same error: EGL_BAD_ALLOC during rendering.
So i think there is something with GPU and this affects application which use GPU for UI.
I have try once Kitkat 4.4.4 and there everything worked fine for some time but then I had weird issues with broken disappearing text in UI of many applications so again ROM is unusable and again graphics problem.
So does anyone have any similar note 4 issues or this is just my broken phone?
Thank you.