I'm writing an app that I've been testing on my Nexus 5 with Android 5 and in the emulator on different DPI and API levels. While some UI magic is missing on pre-L Android, everything worked just fine and I know how to work around these missing parts (e. g. implement touch feedback etc.)
I've implemented RecyclerView and CardView from the support library which worked just fine on my device and the emulators. There is data being fetched from the web so the "list" is being filled upon launch.
Now, I've tested the app on a LG G2 mini running Android 4.4.2. The UI is not being updated. The items are added, but I have to leave the Activity and come back again before I can see them.
This sounds like I've been missing runOnUiThread, but I didn't! Furthermore, why is this working on stock Android but not on an OEMs mod?
Related
I'm currently working with Xamarin for developing an android app. The structure of the app is really simple yet but a big problem appeared concerning the rendering of my main page. First, it's important to know that I'm supposed to develop for target API 23 so Android 6.0.
And every time I test my application on my Android 6.0 device via USB-debugging the design is totally messed up with my only (!) button duplicated many times and the textViews mixed up over the screen (As shown in the picture link below).
Even though I am new to Xamarin and Android (and C#) I have my settings (as I think) in perfect order. The minimum API level is 21, the target SDK version 23 (Android 6.0), my device runs version 6.0.1, the target compiling framework in properties is set to 6.0, the manifest is set up as I mentioned before and even my "Designer" window with the layouts .axml is set to v23.
I really don't know what to try next, because I want to start coding further. Would be nice if sb could help me out with that.
I have already tested the code of the app on a different API level (26 I think) and it worked perfectly fine with my Galaxy S9 in Debugger mode. Everything looked like it was designed in first place.
I also tried different AppThemes in Visual Studio but not one of the 7-8 I tried worked in any way different except for the colors.
The android app does only switch when clicking the button, texthttps://imgur.com/i0xChVniew 2 into the current date and time. I'm really sure, that my code is not the problem.
Picture: How it should look (In Xamarin)
Picture: How it looks on the phone
I have developed an application which uses Cordova/Phonegap on Android to display Open Layers 3 maps.
It is quite similar to this project:
https://github.com/netgis/ol3
I have found that the application runs smoothly on the Samsung Note 4 running Kitkat V4.4.4, and runs fine on an old S2 running Jellybean (almost equally well in fact), but it runs terribly slowly on a bran new Galaxy Tab Pro 12.2 running KitKat V4.4.2.
I was wondering if there is any Cordova/Phonegap expert out there who might know why.
The only difference between them that I can see is the version of android! V4.4.4 and V4.4.2.
I have discovered threads on SO which generically say that WebView can be a problem and cause slow performance, but I'm getting great performance on my Note 4, and the S2 runs better than the tablet does using Jellybean.
I'm not sure code would be useful to show here, essentially I have a Cordova Android application with a single HTML document with Open Layers 3 map embedded, that's it.
The problem turns out to lie with WebView, which uses the default Android browser. For some reason this browser restricts CPU support if you're trying to use GPU acceleration (enabled by default), but doesn't provide GPU acceleration itself (it's really strange but true).
Apparently KitKat has this problem prior to Android V4.4.3. So if you're running V4.4.4 you won't encounter this performance problem as it has been fixed (as it uses Chromium instead of the default browser).
Here's one of many references I've found which corroborate this:
https://code.google.com/p/chromium/issues/detail?id=315111
Some devices haven't yet been updated to this level, here are my completely up to date devices:
The tablet uses Android V4.4.2
The S2 uses Android V4.0.2
The Note 4 uses Android V4.4.4
The S2 uses Jelly Bean and is therefore fine, the Note 4 uses the updated KitKat and also runs fine, but the tablet struggles with the application to such an extent it is unusable owing to it being below V4.4.3.
For me, the majority of suggested solutions on SO are to disable hardware acceleration, but these suggestions are unsuitable as my application really does require hardware acceleration to render maps efficiently.
The solution is to take this problem away completely by forcing the use of Chromium irrespective of the OS Version through the use of Crosswalk.
There are plenty of resources I've found to use Cordova in synergy with crosswalk:
https://crosswalk-project.org/documentation/cordova.html
https://blog.nraboy.com/2014/10/use-crosswalk-ionic-framework-android-apps/
I working on my first Android app (published on iOS and Windows Phone before). When testing the app on a Nexu 5 eveything works fine but on a Kindle Fire the app crashes:
java.lang.IllegalStateException: Cannot add header view to list -- setAdapter has already been called.
This is NOT about the exception itself. I could easily solve the problem by simple using listView.addHeaderView(...) before using listView.setAdapter(...). Not a big deal, but why does the same code runs without any problem on one device but crashes on the other?
I would understand the problem if the devices would use different Android/SDK versions but this is not the case. Both devices run Android 4.2.2 with SDK Level 17...
I would understand the problem if it would be related to something close to the hardware or some vendor specific system calls, but this not the case. It is just about setting up a ListView...
So, what is the difference?
Of course I have only a limited set of test devices. How can I be sure that the app will work on all devices that are running a supported SDK Level?
EDIT:
Of course one device is a phone and the other a tablet. To app uses different layouts for large screens at some places but problem also shows up in Activities/Fragments that have the same layout on both devices. Additionally no separated code for large devices is used. Using the same code and the same layout on both devices leads to a crash on the Kindle but runs on the Nexus...
We are evaluating Delphi XE5 specifically to see how easy it is to develop mobile apps. We have developed a simple Android app that scrolls through a TClientDataset using a DBNavigator. The application comprises a few input fields, labels and slider controls (TSwitch).
Everything works ok and sliders (animations) are responsive, except on a Google Nexus 10 (Android 4.3) where everything happens in slow motion. It is like the app is still running in emulator mode. (A sliding button takes over 2 seconds to move from left to right!)
We have successfully tested the app on a Samsung Galaxy S3 (Android 4.1.2) and a HTC One (4.2.2) and the UI is as responsive as one would expect.
Update.
We asked the question at Code Rage 8 and they are referring it to the R&D Department. Will update when or if we get an answer.
I see mention of the screen resolution in comments. Has it actually been determined that it is the screen resolution that is the issue here?
Can you go into the developer options on the Nexus and try anything there that forces GPU usage or whatever might potentially help things along graphics-wise?
And is there anything clue-like in logcat? Run monitor.bat in the Android SDK tools directory or, if the path to it has spaces in, then that won't work so run ddms.bat instead from the same location (DDMS doesn't abort due to spaces in the path).
It would be good to get more evidence on the problem, rather than (educated) guesswork.
If it turns out to be screen size, well that will be interesting for Embo.
I am working on a project where we are creating an Android app that requests data from a server to be displayed on the user's device (not sure how much more background information I can give... will try my best if more is needed). We are supporting from Gingerbread (2.3) and upwards (up to latest JellyBean 4.2).
Now the odd thing is that the app runs very fast and smoothly on phones that are running 2.3.x (these are in general, slightly older devices such as LG Optimus 2X), while if we try and run the app on relatively newer devices (Galaxy s3 etc.) that have JellyBean 4.1+, the app runs so slow that the performance becomes a usability issue. This occurs on screens that pulls data from the servers and displays them.
I have also confirmed this behaviour by running it on the emulator.
So I did some research based on the fact that we get the following in LogCat for only 4.1+:
06-29 23:11:17.796: I/Choreographer(691): Skipped X frames! The application may be doing too much work on its main thread.
So it seems like this thing called Choreographer was added for API lvl 16, and it coordinates timing of animations, inputs and drawings.
I'm wondering if this is causing this issue? Seems unlikely to be a hardware issue, our app doesn't have any animations and we do not have separate implementations for 2.3.x and 4.1+
Thanks
Starting with Ice Cream Sandwich, the default behavior of AsyncTask has changed from a parallelized executor to a serialized one.
As you are executing several network requests in a batch of AsyncTask (as seen in comment), that means your application waits for the previous request response before lauching the next one.
You can change the executor of an AsyncTask using this code:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
myTask.executeOnExecutor(AsyncTask.THREAD_POOL_EXECUTOR);
}
else {
myTask.execute();
}
Source: AsyncTask Threading Regression Confirmed from CommonsWare blog.
I has experienced the same thing on Kindle Fire, Sony Xperia Z and Samsung S4 (all with android 4.2).
The fix is: at App Manifest file remove "android:supportsRtl="true"".
Hope it will save your time. I spend 4 hours on tests and merging before i got it.