I put together my first Mono for Android project (targeting API level 8, minimum Android 2.2) and deployed it to an HTC Incredible [1] running 2.3.4. Everything worked great and breakpoints in my main activities OnCreate, OnStart, OnResume, OnPause, and OnStop all triggered as described on Xamarin's Activity Lifecycle tutorial.
Without changing any project settings, I swapped for a Samsung Galaxy Nexus running 4.0.2 and deployed the same app. It called OnCreate just fine, but never triggered any of the other events when I switched away from the app.
How do I get these activity events to trigger in Ice Cream Sandwich (ICS) on the Galaxy Nexus?
While running the first deployment on a Galaxy Nexus, you will see it deploying the "armeabi-v7a - 40202" assemblies. For some reason that stuck in my head when this issue started making things difficult.
If you go to the project properties and check the box for "armeabi-v7a" under "Supported architectures", these events will start being triggered as expected.
Related
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?
I noticed a strange issue with my app on a Galaxy S4 LTE updated to Android 4.4.2.
If i go back to the launcher with the home button and try to reopen my application from the launcher menu, it restarts from the main activity instead of resuming from where it was send on background. Issue isn't present if I go back on my app from the task manager.
The issue isn't present on my Nexus devices (7 2012 with some months old CM11 build and 5 with last Cyanogenmod rom) and another Samsung Device (Galaxy Ace 2 I8160 running 4.1.2) I tested my app on.
Other apps behaviour are correct on the Galaxy S4 (IE: Facebook resumes correctly) so I think I'm missing some flags on my AndroidManifest.xml. Any help?
In my app Toasts have worked fine until my RazrM phone was upgraded to 4.4.2. then they stopped. I have tried specifically runInUiThread and moving the call to initiate from different places in the code including in onCreate(). The issue [20373751] (Toast not appearing on Android 4.4 KitKat) proposes rebooting or specifically running on the UI thread. Neither makes a difference.
That issue also questions if there is a bug in Nexus or KitKat. I have the Toasts running fine in 4.0.4 on a Samsung Galaxy Tab. So I am thinking the problem is in 4.4. Has anyone found a workaround? (BTW I am compiling to a target of Version 9, so it is not an issue with the compile level.But I am using the infamous 23.0.2 SDK.) Can anyone prove that Toasts work under 4.4.2 while using SDK 23.0.2?
In [21098062] #marcin_j said:
On Jelly Bean 4.1 or higher,you can disable apps notifications from device settings. Just open notification bar, long tap on any of notifications and click App Info, you should see “Show notifications”. Unchecking this option should disable toasts in your app.
If your app does not show any notifications, then you should be able to reach App Info screen from applications manager.
Maybe this is the cause of you missing toasts
This was absolutely correct. My 4.0.4 device was not affected but my 4.4.2 device had had Show notifications unchecked.
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...
I'm developing for android (API 14) deploying for Nexus One on Genymotion simulator and to a Galaxy Note N8000 tablet, but my app it's having a strange behaviour: in one of the activities, when I press the back button, the app shows the right activity but my debugger disconnects.
Using the simulated Nexus One I have a log message related to OpenGL out of memory and I've found out that OpenGL support for simulators it's usually bad, but using physical note n8000 I have nothing in my logs that can help me. The app behaves like it should but I loose debugging.
Does anyone had a problem similar to that? How did you fix it?
I face the same issue sometimes, my guess is that the Exception actually forces application closing (disconnecting it from debugger), but somehow it gets automatically restarted restoring the previous 'state'.
In your case, maybe is just a simulator issue, but you should consider testing in a real Nexus One device, just to make sure.