How can I find what is stopping my activity - android

I have a single activity with a couple of fragments that is being stopped randomly and I'm trying to figure out the cause. Similar issue to this (Why is my android activity being stopped?) but unrelated answer.
The activity is running on Android Wear, with accelerometer data being collected. It only stops if I also interact with the device while moving it, like tapping the screen. I've tried:
Disabling orientation changes in case shaking the device causes config changes.
Disabling swipeToDismisson the Wear activity in case a tap was misinterpreted as a fast swipe to close.
Overriding onLowMemory() with breakpoints to check if it is a resource issue.
Overriding onFinish() with breakpoints in case of an unintentionall call to finish()
The activity is started from a service with
Intent startIntent = new Intent( this, WearActivity.class );
startIntent.addFlags( Intent.FLAG_ACTIVITY_NEW_TASK );
startActivity( startIntent );
with the activity set to android:launchMode="singleTask", but there is only one start request.
I've run out of ideas. Is there any way to determine who is sending the stop message? Below is a complete stack trace, the activity is stopped by receiving the STOP_ACTIVITY_HIDE system message in ActivityThread.handleMessage():
at myRandomApp.WearActivity.onStop(WearActivity.java:76)
at android.app.Instrumentation.callActivityOnStop(Instrumentation.java:1212)
at android.app.Activity.performStop(Activity.java:5387)
at android.app.ActivityThread.performStopActivityInner(ActivityThread.java:3196)
at android.app.ActivityThread.handleStopActivity(ActivityThread.java:3245)
at android.app.ActivityThread.access$1100(ActivityThread.java:138)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1236)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:136)
at android.app.ActivityThread.main(ActivityThread.java:5026)
at java.lang.reflect.Method.invokeNative(Method.java:-1)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:777)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:602)
at dalvik.system.NativeStart.main(NativeStart.java:-1)
EDIT:
In response to some comments, the above stack trace was not generated by an exception being thrown. It is just where I hit a breakpoint to see the history of calls leading up to the app being stopped. The app exits cleanly, I'm trying to figure out why it wants to quit at all.
UPDATE:
I've finally found the culprit. Invariably, before my app shuts down, I get this a few moments earlier in the log output:
I/ActivityManager﹕ START u0 {act=android.intent.action.MAIN cat=[android.intent.category.HOME] flg=0x10000000 cmp=com.google.android.wearable.app/com.google.android.clockwork.home.HomeActivity (has extras)}
It appears moving the watch about increases the pedometer step count, which causes a new info card to be shown on the home screen of the watch. This card interrupts my full screen activity and closes it. Does anyone know of a way to prevent that? It feels like a Wear bug, I'm not sure other apps should be able to interrupt a running foreground application like that.
I've found the reason why my app shuts down, but only due to a lucky bit of info sent to the log. I'm still looking for an answer to my original question, for a general way to determine the reason for the Android system stopping apps. Maybe that is just not possible?

I don't have an answer for my original question, but I have a workaround for the symptoms caused by it. Rather than starting my app as a full screen activity, I instead create a notification in the context stream with an action to go fullscreen. The notification is persistent, so even when other cards enter the stream, they don't cause my task to quit.
Iv'e filed a bug for this issue at https://code.google.com/p/android/issues/detail?id=75918&thanks=75918&ts=1410235765
The original question remains open, but I suspect it has no answer...

Related

context.startActivity in broadcast receiver sometimes not working (targetSDK 19 on an SDK 27 device)

I call startActivity in an implicit broadcast receiver's onReceive function under certain very limited circumstances.
Intent transactionIntent = new Intent(context, TransactionActivity.class);
transactionIntent.putExtra(Constants.Extras.ORDER_ID, orderId);
transactionIntent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_ACTIVITY_CLEAR_TASK);
context.startActivity(transactionIntent);
I have logs before this line and logs in the onCreate function of the activity. Some customers are reporting random instances of this activity not creating itself. I can see in the logs that startActivity is called and onCreate is not. One of them I know for sure is an Android 8.1 Oreo device. My target SDK is 19 (vast majority are old devices, this is not an app on the Play store). I can also tell the Background activity toggle in the system settings for the app is not switched off so that is not the problem.
What situations can this happen (extreme memory pressure?) and how can I capture it to verify what is going on?
EDIT:
The app is not crashing (no crashes logged for this version of the app, and it does nothing but setContentView before logging the activity creation). I don't think device sleep is an issue because I am targeting pre M, doze mode etc. doesn't come in to play. The user was also using the app a few seconds before this call to startActivity failed, and 30 seconds later they were using the app as well, so that window doesn't seem likely large enough to allow for any kind of sleep or wake lock issues. I also don't think the user could have managed to swipe the app out of memory between the app calling startActivity and onCreate, this is happening sporadically (for this one user is happened 1 out of 6 times).
The app is a for a busy, mains connected Point of Sale device.

DeadSystemException start service Android 7

For the past few weeks, I have on my crash reporter:
Fatal Exception: java.lang.RuntimeException: Unable to start service com.####.MyService#ef705d8 with Intent { act=HIDE cmp=com.####/.MyService (has extras) }: java.lang.RuntimeException: android.os.DeadSystemException
at android.app.ActivityThread.handleServiceArgs(ActivityThread.java:3344)
at android.app.ActivityThread.-wrap21(ActivityThread.java)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1583)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:6121)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:889)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:779)
This crash is present on:
all Samsung devices 7.0
all Nexus devices on 7.1.2
Note:
It is not due to a recent update of our application, just an OS updates on theses phones.
It is a very very frequent crashes (by far our biggest).
Our users don't report crashes than before (is this crash actually visible for the user?)
We are not able to reproduce it on our side
As you can see into the stack trace, the code impacted is system only. Not much I can do from my side to try and catch and handle the issue.
I checked the thread Android DeadSystemException but that doesn't help me much.
I know that DeadSystemException is:
The core Android system has died and is going through a runtime restart. All running apps will be promptly killed.
Is there anything we can do but to say "that's system, we cannot do anything"?
When the device is being restarted, you cannot run an app. Any app, not just yours but any given app cannot run when the device is restarting. AFAIK it occurs when you try to do something when the system crashes. Meaning if the system crashes and as it restarts your app starts a service or does something you get that error.
Meaning the exception is not connected to your app, but the Android OS and there is nothing you can do about it.
The crash being related to starting a service is because that is what your app did when the system crashed.
So: The error is something the system threw because your app did something when the system did a run-time reboot. There is nothing you can do about this, as you cannot control the Android OS from an app.
I've had the same issue. I implemented a service that uses the android SensorService. In some point of the time, two things happened but I still don't know which one caused the other. 1) The runtime restarted 2) The android SensorService died. I have implemented a default unhandled exceptions handler because I was debugging some other stuff on my app. I noticed that such handler, at least sometimes was catching that exception.
I followed this tutorial to implement it https://doandroid.wordpress.com/2011/11/19/writing-crash-reports-into-device-sd-card/
So, supposing that you implement this handler and it is actually being called when the system dies, you can add some sort of validations inside the handler such that if the exception is the DeadSystemException, you can set up an alarm to restart your application in let's say, 5 minutes or something.
This is of course not an ideal solution, but at least might be a workaround to your problem until you figure out what is really going on with the system.
Some information about how to restart you app programmatically:
Force application to restart on first activity
Your app crashed because of android OS system dies.
Here is the reference.
https://developer.android.com/reference/android/os/DeadSystemException
The core Android system has died and is going through a runtime restart. All running apps will be promptly killed.

Avoid Screen Overlay Detected for service that uses SYSTEM_ALERT_WINDOW

My app main usage is overlay, the overlay is running from a service.
Android Security add the nice "Screen Overlay Detected"
I want to avoid "Screen Overlay Detected" when user tries to change permissions. so... I've add an AccessiblityService that detects:
if ( event.getPackageName().equals("com.google.android.packageinstaller") ){
stopService(myServiceIntent);
}
However, even now I see this message popping. (when my service is stopped...).
I saw Twilight does it without problem.
What am I missing?
p.s. - I've also tried building a signed apk but saw exact same behavior.
It seems I've been able to resolve this.
a) stopService isn't assured your service will be stopped.
as described here :
It will not be destroyed until all of these bindings are removed. See > the Service documentation for more details on a service's lifecycle.
b) I was able to kill my service by sending intent that called stopSelf().
However process killing/starting can be slow.
c) Best resolution: so it seems Android checks for view visibility. no need to kill services or do anything more complicated.
Current way I'm doing it:
- AccessibilityService (already used by my app) monitor "com.google.android.packageinstaller" though it can be refined to class: "com.android.packageinstaller.permission.ui.ManagePermissionsActivity"
Once detected in this class, we send Intent to "duck", and when we're out, we send another intent that we're back on.
The service handles those calls by:
[ourView].setVisibility(View.INVISIBLE); // when permission settings shown
[ourView].setVisibility(View.VISIBLE); // when normal flow
As long as Android 6.x is buggy on some devices where this "overlay alert" is displayed without any reason (on 2 to 5% of the devices according to my analytics data), the best solution is to avoid the whole permission process by defining the targetSdk to 22. Take care that you can't downgrade the target sdk for a new version or this will induce a INSTALL_FAILED_PERMISSION_DOWNGRADE error when the user updates requiring an unisntall/install of the app.

Logcat full of "Wtf, activity ActivityRecord" entries

I am getting thousands of the following warning message in my logcat, and it's crowding out the messages that I'm actually looking for:
W/ActivityManager﹕ Wtf, activity ActivityRecord{4338cd90 u0 us.bridgeses.Minder.debug/us.bridgeses.Minder.MainListActivity t269 f} in proc activity list not using proc ProcessRecord{4289a348 4821:us.bridgeses.Minder.debug/u0a246}?!?
Possibly related, my phone is now occassionally popping up the "Waiting for debugger process" dialog even when my phone is unplugged and the app is in the background. It only stops if I uninstall it, and starts up again the next time I debug. Any ideas?
Edit:
I just commented out my entire MainListActivity class. My app is now literally doing nothing except creating an empty Activity. I'm still getting tons of this message, and I'm still getting this message.
Edit 2:
This is getting really weird. I uninstalled the debug app, did not reinstall it, and I'm still getting this message.
This message comes from the Android OS. It happens when your activity is not destroyed correctly. Therefore the ActivityRecord is still there, but the corresponding proc is not. By rebooting, all records will lost, so you would not see any of these errors.
Typically this happens when a active/foreground activity component is being disabled. Such as calling packageManager.setComponentEnabledSetting() method to disable current active activity component.
I restarted my phone and the error has not recurred for 10 minutes. It's not really an answer, but I guess it's a resolution.

Atooma plugin stops working

I made a simple plugin for Atooma: performer plugin to change a wallpaper photo upon trigger: Screen On. After it triggered this action couple of times after some time it stopped working: in Atooma notification it always says that it has been triggered but my performer doesn't get called: I made sure by putting couple of log calls inside performer.
I checked the logs and these may provide some clue:
threadid=17 (Thread-6653): calling run()
android.os.DeadObjectException
at android.os.BinderProxy.transact(Native Method)
at com.atooma.plugin.r.a(Unknown Source)
at com.atooma.plugin.z.a(Unknown Source)
at com.atooma.engine.t.run(Unknown Source)
at java.lang.Thread.run(Thread.java:838)
threadid=17: exiting
This log message appears every time when trigger is activated ('screen on' in my current case)
Another symptom is that when I look at my task in Atooma, I don't see DO part where my performer action was - no icons, after DO nothing shows (description bellow is ok). When I try to edit it - Atooma crashes: dialog message appears: "Unfortunately, Atooma has stopped. Report/Ok". If I click OK Atooma obviously get restarted showing me again my task, icons for my performer are still missing but when I click edit it works this time. Performer again works upon trigger but after a while it stops working again with same exceptions as above listing from log every time it gets triggered.
Any suggestion is appreciated
Yes, I saw the same problem. It happens when the Atooma service died or something internal to Atooma happens (the plug communicates with Atooma via aidl remote service). The only option is to uninstall and install the plug again. Report this behavior to the Atooma team.

Categories

Resources