My app got "android.app.RemoteServiceException" exception. I've use the "JobScheduler" to instead of "Service". It worked, besides OPPO 8.1.
That's all message i got.
android.app.ActivityThread$H.handleMessage(ActivityThread.java:1987)
android.os.Handler.dispatchMessage(Handler.java:106)
android.os.Looper.loop(Looper.java:187)
android.app.ActivityThread.main(ActivityThread.java:7025)
java.lang.reflect.Method.invoke(Native Method)
com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:514)
com.android.internal.os.ZygoteInit.main(ZygoteInit.java:888)
This was happening for me too after migrating to JobScheduler. Turned out there were some alarms scheduled by the previous app version that would still try to launch the migrated service in the foreground. I fixed it by renaming the JobService class, that way the system could no longer locate it when one of those prior alarms would trigger.
Related
I get this exception on occasion:
Context.startForegroundService() did not then call
Service.startForeground() android.app.ActivityThread.main
The fun thing is I have no idea from the stack traces when or where startForegroundService is being called. I know it's not in my code, but it could be in one of the 3rd party libs I'm using. Unfortunately, the stack traces are all but useless. Of course, I can't reproduce it reliably, that would be too easy! Does anyone have any tips/ideas on how to track down the origin?
Fatal Exception: android.app.RemoteServiceException: Context.startForegroundService() did not then call Service.startForeground()
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1790)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loop(Looper.java:164)
at android.app.ActivityThread.main(ActivityThread.java:6651)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:810)
If it is crashing "in the lab", you could look at Logcat to see what service was started ~10 seconds before the crash.
Beyond that, use the "Merged Manifest" tab in Android Studio's manifest editor and see what services are showing up in your manifest (plus, what libraries contributed those manifest entries). That at least narrows down which libraries might be the culprit. If any of those are open source, you could then poke through the source code to see if they seem to call startForegroundService().
I have an Android alarm clock app. I have the usual(?) alarm Intent -> receiver -> activity chain, whose last step creates a full-screen window and sounds the alarm.
All this works fine on pre-Oreo (API 26) versions of Android. But on Oreo, when the alarm fires, the System UI crashes and I get this exception in the emulator (slightly reformatted here):
12-12 01:15:02.864 9570-9570/com.android.systemui E/AndroidRuntime:
FATAL EXCEPTION: main
Process: com.android.systemui, PID: 9570
java.lang.NullPointerException: Attempt to invoke virtual method 'void com.android.systemui.statusbar.phone.NavigationBarFragment.onKeyguardOccludedChanged(boolean)' on a null object reference
at com.android.systemui.statusbar.phone.StatusBar.onKeyguardOccludedChanged(StatusBar.java:3843)
at com.android.systemui.statusbar.phone.StatusBarKeyguardViewManager.setOccluded(StatusBarKeyguardViewManager.java:277)
at com.android.systemui.keyguard.KeyguardViewMediator.handleSetOccluded(KeyguardViewMediator.java:1176)
at com.android.systemui.keyguard.KeyguardViewMediator.-wrap14(Unknown Source:0)
at com.android.systemui.keyguard.KeyguardViewMediator$4.handleMessage(KeyguardViewMediator.java:1531)
at android.os.Handler.dispatchMessage(Handler.java:105)
at android.os.Looper.loop(Looper.java:164)
at android.app.ActivityThread.main(ActivityThread.java:6541)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:240)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:767)
As a possible clue, I've found that when I remove WindowManager.LayoutParams.FLAG_SHOW_WHEN_LOCKED from win.addFlags(), it doesn't crash -- but of course, it also doesn't show the alarm when the phone is locked.
I don't remember everything I've tried, but here are some of the things:
Locating Android's StatusBar.java source code to try to figure out exactly what thing is null that's not supposed to be. My Google-fu has failed me here, apparently.
Explicitly dismissing the keyguard with something like getSystemService(KeyguardManager.class).requestDismissKeyguard(this, null);.
Dismissing the keyguard by using WindowManager.LayoutParams.FLAG_DISMISS_KEYGUARD.
Both explicitly showing and explicitly hiding the status bar.
I think I tried some other method of showing the window when locked -- like, calling setShowWhenLocked(true) or something like that. But it didn't help, and anyway that method was added only in API 27, so it wouldn't solve the problem for API 26 even if it had worked.
Um ... other things I no longer remember.
None of these has had any effect.
Clearly this can work, because other alarm clock apps work under Oreo. What am I doing wrong?
Known bug that has been fixed it seems. Especially on the emulator.
So update the image used in the emulator.
It was present in the original Oreo release it seems according to the history if I interpret it correctly. Fixed in 8.0.0_r21 and later, present in 8.0.0_r17 and earlier and can't see any between those).
What exact versions of Oreo, have you tried 8.1 and/or various patch levels?
Because it's was fixed Sep 20 according to this commit, maybe another commit as well:
https://android.googlesource.com/platform/frameworks/base/+/8078996f4a8b1718a2ca56ff52fd1f4d522e7720%5E1..8078996f4a8b1718a2ca56ff52fd1f4d522e7720/
Possibly:
https://android.googlesource.com/platform/frameworks/base/+/9c4faa85f1bc4ffc2aa949da7b5d8439f4c638a2
Or their related source commit (noticed it was merge commits).
I quote one of them:
Fix random systemui crashes during boot
When trying to boot android in emulator, systemui may crash due to an
uninitialized value of mNavigationBar probably because of some race
condition during initialization caused by emulation performance issues
I have already installed previous version of my application. When I have submitted new version of my application on play store. on my mobile I have updated that new version but when I am going to use some functionality it is giving me following exception
Failed to dispatch window animation state change.
android.os.DeadObjectException
at android.os.BinderProxy.transactNative(Native Method)
at android.os.BinderProxy.transact(Binder.java:503)
at android.view.IWindow$Stub$Proxy.onAnimationStopped(IWindow.java:534)
at com.android.server.wm.WindowAnimator.updateWindowsLocked(WindowAnimator.java:289)
at com.android.server.wm.WindowAnimator.animateLocked(WindowAnimator.java:681)
at com.android.server.wm.WindowAnimator.access$000(WindowAnimator.java:53)
at com.android.server.wm.WindowAnimator$1.doFrame(WindowAnimator.java:123)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:858)
at android.view.Choreographer.doCallbacks(Choreographer.java:672)
at android.view.Choreographer.doFrame(Choreographer.java:605)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:846)
at android.os.Handler.handleCallback(Handler.java:739)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:148)
at android.os.HandlerThread.run(HandlerThread.java:61)
but when I have deleted that application and again downloaded from play store it is working fine all the functionality.
please help me to understand why this happening first time after updating application.
This happened because your a Service or Component in your app has been stopped.
You need to override you Service's or Component's onDestroy() and catch any DeadObjectException to prevent the crash. It happens only when service is killed by OS or application stop.
In Android Developer Documentation at https://developer.android.com/reference/android/os/DeadObjectException.html
it is mention that DeadObjectException occurs when the object you are calling has died, because its hosting process no longer exists.
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.
Background
We have a very large and very popular app with quite a few permissions.
The problem
It seems that on Motorola devices only (XT1254,XT1585,XT1565), with Android 5.1 and 5.1.1, we get crashes of this kind:
Fatal Exception: java.lang.SecurityException: Permission Denial: not allowed to send
broadcast com.motorola.intent.SYSTEM_DIALOG_POPUP from pid=15407, uid=10164
at android.os.Parcel.readException(Parcel.java:1546)
at android.os.Parcel.readException(Parcel.java:1499)
at android.app.ActivityManagerProxy.broadcastIntent(ActivityManagerNative.java:2864)
at android.app.ContextImpl.sendBroadcast(ContextImpl.java:1510)
at android.content.ContextWrapper.sendBroadcast(ContextWrapper.java:382)
at android.content.ContextWrapper.sendBroadcast(ContextWrapper.java:382)
at android.app.Dialog$2.run(Dialog.java:316)
at android.os.Handler.handleCallback(Handler.java:746)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:135)
at android.app.ActivityThread.main(ActivityThread.java:5356)
at java.lang.reflect.Method.invoke(Method.java)
at java.lang.reflect.Method.invoke(Method.java:372)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:905)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:700)
The above statistics were collected using Crashlytics.
Not sure if it is because of this, but one of the app's permission is "SYSTEM_ALERT_WINDOW", to be able to show content on top of other apps.
Thing is, this error seems to be because of Motorola's code itself, and I can't find anything about it over the Internet.
What I've tried
Apart from searching the Internet about this exception, I've also tried to find how to contact Motorola itself, including finding a developer forum, but I've failed in doing so.
I've also tried posting about this on Android's group:
https://code.google.com/p/android/issues/detail?id=201631
The question
What can be done in this case?
Why does it occur? Is it because of the permission? Is there a workaround ?
Hi actually me and my team mates faced the exact same problem when we were building an application which shows notes on top of other applications.
After researching for great lengths we found out that "SYSTEM_ALERT_WINDOW" permissions was made a signature permission and was causing problems by not letting the pop up appear from Lollipop 5.1
As a work around to it we need to explicitly ask the user to grant overlay permission for your app by doing this.
public void checkOverlayPermission(){
if(!Settings.canDrawOverlays(this)){
Intent intent = new Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION,
Uri.parse("package:"+getPackageName()));
startActivityForResult(intent, ApplicationConstants.OVERLAY_PERMISSION);
}
}
Hope this helps