I've confirmed this on Android 2.3.6 and 4.1.2 .. Can't say i did on iOS(Haven't had an extended test on it yet). But here's the deal:
I've got an app which sends it's current coordinates to a php service which saves it to a mysql database and sends a response(usually 1) back to the app as a result. It does this in a 5 second interval and does it in a way i want it to. So basically the app does a fine job. However; If i wait a while the complete app just CLOSES itself at random. It happened to me after 9 hours and 3 hours and there's no real reason to do so. The phone is just laying stationary on my desk basically.
Is there any known issue for titanium apps to just shut down without a crashreport/warning whatsoever?
I imagine you might be violating something about the way the mobile OS runs. Maybe you have a memory leak and the device/emulator sees your app eating all the memory and force closes it. I'm not sure what logs are available on devices to inform you about what just happened. Maybe you'll see the app was closed by the device and a reason why.
Have you profiled your app? I'm going to guess memory leak.
Related
I am struggling with a strange situation with my Android app.
It runs on a 5.1 OS and the device is Rooted.
The app is running fine for a few days and then from an unknown reason it crashes (WIN DEATH without any exceptions from my logs).
I think it related to an internal memory leak on a specific Android model I'm using.
Anyway, I need to restart the app in cases like that.
Unfortunately, using 'Thread.setDefaultUncaughtExceptionHandler' method doesn't help because it won't handle those situations (the app is crushed).
I thought about creating a second app that samples the state of the process and if it is disappears from the process list, it starts the activity.
Is there a more elegant way to handle this situation?
Thanks a lot!
Asaf
a colleague of mine is working on a legacy ReactNative app. There is quite a lot of code both in JavaScript and Java land, the latter being related to HERE Maps SDK.
Two of our clients experience multiple crashes every day and we cannot figure out why as we have no error reports.
Bugsnag was installed early last year (circa jan 2020) and we have nothing on there to help us. Nothing to be found in Google Console either. App just stops.
To help us debug we've added a logging system which sends debug info to our backend via dedicated API calls.
It roughly consists of logging "start of function A", "end of function A" etc so we know what the app is doing. We don't always enable it as it tends to make the app even more unstable.
In parallel to that we managed to get an idea of when the app crashes via login events that are sent by Firebase Auth when user re-launches the app.
Looking at our logs around the time of crash doesn't help us as 1) they look the same as when it all works and 2) we haven't covered all method calls as there are way too many (in JS and Java).
Our users run the app on a Samsung Galaxy Active Tab 2 mounted in the cabin of a tractor. Some use a Galaxy Active Tab 3 and also have the issue.
We have run through various theories :
Could it be too hot in the cabin so Android shuts down? No, tablet is always on according to clients.
Could it be related to a change in voltage? When WE try to plug and unplug everything continues to work fine.
Could it be Android that decides the app is consuming too much battery or CPU (GPS is needed for our app) so it shuts it down? We've let our app in the foreground for hours with no problem.
We logged in with customers' credentials (they are aware) and could not replicate the issue.
Customers interest in helping us find the issue is slowly fading away so we can't keep on asking them to install a patched version every week.
First there was just one client but now we have at least 3 more users complaining about mysterious crashes.
We're a bit stomped as to what to do.
Has anyone any idea of an ultimate catch all library? Or a syslog on the tablet where we could get more info?
Thanks in advance for your help!
After much testing my colleagues managed to easily reproduce the error and found the root cause: poor memory management in one method in Java land.
Said method was responsible for changing markers orientation on the map but it duplicated markers when their orientation changed. It resulted in a high memory consumption and when it reached a certain point Android would just kill all running apps.
My colleague fixed the leak and we're good! Onto the next bug now. :)
The below reasoning is based on hardware failure. If your software hasn't drastically changed (the app or the operating system), then this is a likely scenario:
The Tab 2 was released in 2012, so we're talking about a device that is up to 9 years old. If the users all use the same hardware, and the software hasn't been changed for a while, it could be some kind of hardware failure. It could be related to the vibrations of the tractor, moisture over time, or just because they used the tablet more intensively than you use yours. There could be something (semi-)loose or the memory (SSD or RAM) could start becoming faulty.
It can be a software error too of course, but it's unlikely if you haven't updated in a long time - assuming the tablets haven't been updated either.
Could you perhaps swap your tablet with one of a customer. Preferrably a customer that has the issue most often. Then observe if the issue is resolved.
This way, you'll be able figure out if it is related to the tablet (being broken) or the environment (tractor) it is being used in.
If the issue persists after a tablet swap, it's either the environment or the software, but you'd have ruled out the hardware.
If the issue is resolved, you'll know for sure it's the hardware at fault.
I have a somewhat unusual Android app in the Play Store that's running on dedicated devices 24/7 (it collects sensor data, it's not meant to run on phones used for anything else). I would like the app to auto-update without user interaction, but that never seems to happen. Why could this be?
Some more background:
Auto-update is explicitly turned on for the app on the devices.
Other apps do seem to auto-update.
The app stops and restarts itself every 12 hours; mostly to whack the app out of any weird state it might get into and clear memory, but I was also hoping this would give it a chance to auto-update. There is a 10 second delay until the app restarts.
The devices are mostly old phones (HTC Desire C) running Android 4.0.4
This is fairly hard and time-consuming to test so any experiences shared with similar requirements could be helpful.
Make sure the port 5228, TCP and UDP, is not blocked by a firewall per https://support.google.com/googleplay/answer/2651367?hl=en
We've had a similar problem for years. Our apps run on school deployed devices. Whenever we push an update, it reaches may be 10% of devices within 24 hours, the rest seem to "hang". It takes about a week for another 30% of devices to get the update, while the remaining %60 never get it. There is no difference in settings across devices. All set to auto-update of course.
The way we "solved it" is our app is checking if the market has a newer version (there are libraries for doing it, but we have own server responding yes/no). If there is a newer version of the app, we invoke the intent to open Google Play with the app's page. The user has to manually click "Update" at that point.
If there was a native or cleaner way to push the updates we'd love to hear, even at this point in the game. Bothering users to update is not ideal.
This is a long shot: Maybe there was any change in the apps required permissions?
That would require manual updating (even if auto-update is on). Maybe you installed the app first in those old devices, then changed the permissions, then installed the app in new devices, then updated the app. That would make the autoupdate system work in the newer devices, and not work in the older ones.
I have written an android app that generates a strange exception on the LG-Phone I have just started testing on. In DDMS the tag is "ISP_LOG_MW_DEBUG" and the text is "AMI_IsWindowSearch()." It is generated about 10 times per second while the app is running. It doesn't seem to interfere with the program itself, but I would rather not have this error. but I can not find any information on this on the web.
If a click the home button (the app continues running in the background) and start the app again (new UI, with the old services) the amount of these messages increases each time. So it is reasonable to assume that they are generated by something in the UI.
Has anybody experienced this error or has any idea how to avoid it?
Real devices can sometimes make a lot of noise. Sometimes the vendors just leave a lot of debugging turned on. If your app is not crashing, or showing performance issues, I would say it's safe to ignore.
Also, try with another device, or try with the emulator. If you don't see those errors with another device or the emulator, I think it's safe to say the vendor developers of the the LG device are just lazy and didn't turn off all their debugging like a good developer should. :D
db
I hope you're all good. I am working on an android application project and I mostly use android emulator for testing the application. Android Emulator takes too much time for application loading and since I am working on the design I have to run the application after a few seconds again and again. Because of slow emulator I think my time is wasted and I can't focus on the work.
I recently tried my Galaxy Note for running application and its quite fast and running experience is much better. What I wanted to know is.. Does running eclipse project on my Phone will harm my mobile phone in any way?
Because moments back while using the phone the screen got stuck and the icons changed to different green, red and blue color. I restarted the phone and its acting normal now. But I wanted to know if it happened because of the eclipse project running on the phone? Is it safe ?
It is possible to harm your phone.
Apart from the wear and tear (YMMV) of repeatedly flashing your app to memory you may unwittingly (or otherwise) create a virus.
I've been in a situation where a thread has run amok after the app terminated and hogged the processor slowing things down. It did eventually quit though (possibly after elective rebooting). I've often had my phone restart when debugging on it. I wouldn't worry too much about that (although my domain was Samsung's bada, a lot less robust platform).
I don't see too many risks with Java apps as the language is so well managed. Native code is a risk in that, at least, a buffer overflow could place unwanted code outside of the process address space and so escape being cleaned up when the app quits. A shut down and/or force close may result from such errors.