Obsolete
Status Update
No update yet.
Comments
mm...@commonsware.com
First of all, sorry for my poor english.
I really agree.
My app crashes only in cetain phone even if the build number is same!
09-23 11:05:53.718: E 754 Parcel Class not found when unmarshalling: com.samilcts.mpaio.data.Receipt
09-23 11:05:53.718: E 754 Parcel java.lang.ClassNotFoundException: com.samilcts.mpaio.data.Receipt
09-23 11:05:53.718: E 754 Parcel at java.lang.Class.classForName(Native Method)
09-23 11:05:53.718: E 754 Parcel at java.lang.Class.forName(Class.java:251)
09-23 11:05:53.718: E 754 Parcel at java.lang.Class.forName(Class.java:216)
09-23 11:05:53.718: E 754 Parcel at android.os.Parcel.readParcelableCreator(Parcel.java:2133)
09-23 11:05:53.718: E 754 Parcel at android.os.Parcel.readParcelable(Parcel.java:2097)
09-23 11:05:53.718: E 754 Parcel at android.os.Parcel.readValue(Parcel.java:2013)
09-23 11:05:53.718: E 754 Parcel at android.os.Parcel.readArrayMapInternal(Parcel.java:2314)
09-23 11:05:53.718: E 754 Parcel at android.os.Bundle.unparcel(Bundle.java:249)
09-23 11:05:53.718: E 754 Parcel at android.os.Bundle.getString(Bundle.java:1118)
09-23 11:05:53.718: E 754 Parcel at android.content.Intent.getStringExtra(Intent.java:4991)
09-23 11:05:53.718: E 754 Parcel at com.android.server.am.ActivityStackSupervisor.startActivityLocked(ActivityStackSupervisor.java:1394)
09-23 11:05:53.718: E 754 Parcel at com.android.server.am.ActivityStackSupervisor.startActivityMayWait(ActivityStackSupervisor.java:1026)
09-23 11:05:53.718: E 754 Parcel at com.android.server.am.ActivityManagerService.startActivityAsUser(ActivityManagerService.java:3984)
09-23 11:05:53.718: E 754 Parcel at com.android.server.am.ActivityManagerService.startActivity(ActivityManagerService.java:3887)
09-23 11:05:53.718: E 754 Parcel at android.app.ActivityManagerNative.onTransact(ActivityManagerNative.java:159)
09-23 11:05:53.718: E 754 Parcel at com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:2576)
09-23 11:05:53.718: E 754 Parcel at android.os.Binder.execTransact(Binder.java:404)
09-23 11:05:53.718: E 754 Parcel at dalvik.system.NativeStart.run(Native Method)
09-23 11:05:53.718: E 754 Parcel Caused by: java.lang.NoClassDefFoundError: com/samilcts/mpaio/data/Receipt
09-23 11:05:53.718: E 754 Parcel ... 18 more
09-23 11:05:53.718: E 754 Parcel Caused by: java.lang.ClassNotFoundException: Didn't find class "com.samilcts.mpaio.data.Receipt" on path: DexPathList[[directory "."],nativeLibraryDirectories=[/vendor/lib, /system/lib]]
09-23 11:05:53.718: E 754 Parcel at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:67)
09-23 11:05:53.718: E 754 Parcel at java.lang.ClassLoader.loadClass(ClassLoader.java:497)
09-23 11:05:53.718: E 754 Parcel at java.lang.ClassLoader.loadClass(ClassLoader.java:457)
09-23 11:05:53.718: E 754 Parcel ... 18 more
I really agree.
My app crashes only in cetain phone even if the build number is same!
09-23 11:05:53.718: E 754 Parcel Class not found when unmarshalling: com.samilcts.mpaio.data.Receipt
09-23 11:05:53.718: E 754 Parcel java.lang.ClassNotFoundException: com.samilcts.mpaio.data.Receipt
09-23 11:05:53.718: E 754 Parcel at java.lang.Class.classForName(Native Method)
09-23 11:05:53.718: E 754 Parcel at java.lang.Class.forName(Class.java:251)
09-23 11:05:53.718: E 754 Parcel at java.lang.Class.forName(Class.java:216)
09-23 11:05:53.718: E 754 Parcel at android.os.Parcel.readParcelableCreator(Parcel.java:2133)
09-23 11:05:53.718: E 754 Parcel at android.os.Parcel.readParcelable(Parcel.java:2097)
09-23 11:05:53.718: E 754 Parcel at android.os.Parcel.readValue(Parcel.java:2013)
09-23 11:05:53.718: E 754 Parcel at android.os.Parcel.readArrayMapInternal(Parcel.java:2314)
09-23 11:05:53.718: E 754 Parcel at android.os.Bundle.unparcel(Bundle.java:249)
09-23 11:05:53.718: E 754 Parcel at android.os.Bundle.getString(Bundle.java:1118)
09-23 11:05:53.718: E 754 Parcel at android.content.Intent.getStringExtra(Intent.java:4991)
09-23 11:05:53.718: E 754 Parcel at com.android.server.am.ActivityStackSupervisor.startActivityLocked(ActivityStackSupervisor.java:1394)
09-23 11:05:53.718: E 754 Parcel at com.android.server.am.ActivityStackSupervisor.startActivityMayWait(ActivityStackSupervisor.java:1026)
09-23 11:05:53.718: E 754 Parcel at com.android.server.am.ActivityManagerService.startActivityAsUser(ActivityManagerService.java:3984)
09-23 11:05:53.718: E 754 Parcel at com.android.server.am.ActivityManagerService.startActivity(ActivityManagerService.java:3887)
09-23 11:05:53.718: E 754 Parcel at android.app.ActivityManagerNative.onTransact(ActivityManagerNative.java:159)
09-23 11:05:53.718: E 754 Parcel at com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:2576)
09-23 11:05:53.718: E 754 Parcel at android.os.Binder.execTransact(Binder.java:404)
09-23 11:05:53.718: E 754 Parcel at dalvik.system.NativeStart.run(Native Method)
09-23 11:05:53.718: E 754 Parcel Caused by: java.lang.NoClassDefFoundError: com/samilcts/mpaio/data/Receipt
09-23 11:05:53.718: E 754 Parcel ... 18 more
09-23 11:05:53.718: E 754 Parcel Caused by: java.lang.ClassNotFoundException: Didn't find class "com.samilcts.mpaio.data.Receipt" on path: DexPathList[[directory "."],nativeLibraryDirectories=[/vendor/lib, /system/lib]]
09-23 11:05:53.718: E 754 Parcel at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:67)
09-23 11:05:53.718: E 754 Parcel at java.lang.ClassLoader.loadClass(ClassLoader.java:497)
09-23 11:05:53.718: E 754 Parcel at java.lang.ClassLoader.loadClass(ClassLoader.java:457)
09-23 11:05:53.718: E 754 Parcel ... 18 more
cc...@gmail.com
I also see the same few reports (usually after an update) and users sometimes complain with bad reviews about it too.
java.lang.RuntimeException: Unable to instantiate applicationcom.mindmeapp.alarmpad.App : java.lang.ClassNotFoundException: Didn't find class "com.mindmeapp.alarmpad.App " on path: DexPathList[[],nativeLibraryDirectories=[/vendor/lib, /system/lib]]
at android.app.LoadedApk.makeApplication(LoadedApk.java:507)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4301)
at android.app.ActivityThread.access$1500(ActivityThread.java:135)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1256)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:136)
at android.app.ActivityThread.main(ActivityThread.java:5001)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:785)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:601)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.ClassNotFoundException: Didn't find class "com.mindmeapp.alarmpad.App " on path: DexPathList[[],nativeLibraryDirectories=[/vendor/lib, /system/lib]]
at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:56)
at java.lang.ClassLoader.loadClass(ClassLoader.java:497)
at java.lang.ClassLoader.loadClass(ClassLoader.java:457)
at android.app.Instrumentation.newApplication(Instrumentation.java:975)
at android.app.LoadedApk.makeApplication(LoadedApk.java:502)
... 11 more
java.lang.RuntimeException: Unable to instantiate application
at android.app.LoadedApk.makeApplication(LoadedApk.java:507)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4301)
at android.app.ActivityThread.access$1500(ActivityThread.java:135)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1256)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:136)
at android.app.ActivityThread.main(ActivityThread.java:5001)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:785)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:601)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.ClassNotFoundException: Didn't find class "
at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:56)
at java.lang.ClassLoader.loadClass(ClassLoader.java:497)
at java.lang.ClassLoader.loadClass(ClassLoader.java:457)
at android.app.Instrumentation.newApplication(Instrumentation.java:975)
at android.app.LoadedApk.makeApplication(LoadedApk.java:502)
... 11 more
mm...@commonsware.com
An "operating system" that can't handle properly installing apps?
Hope it's not that, but rather crazy green aliens from outer space... :)
Hope it's not that, but rather crazy green aliens from outer space... :)
cc...@gmail.com
It happens when the other sisutation.( not only "Google Play" problem)
In my case, this issue came out when it pass the custom parcelable array between the activities.
I have two phone that same android version(4.4.2).
And testing my app,
it is occurred at the one. but it does not occurred at the other phone.
In my case, this issue came out when it pass the custom parcelable array between the activities.
I have two phone that same android version(4.4.2).
And testing my app,
it is occurred at the one. but it does not occurred at the other phone.
mm...@commonsware.com
Wait, using a custom parcelable and not being able to unparcel it (e.g. when restoring a fragment) gives the parcelable class name in the call stack, and mostly happens on 2.* device (Android 4.* sets the class loader on bundles).
So it looks like a different issue.
So it looks like a different issue.
cc...@gmail.com
I have a very similar issue. The class specificaaly Click extends application in this case. Runs fine from eclipse in VM or on multiple devices but crashes with this error 100% of the time when downloaded from playstore.
java.lang.RuntimeException: Unable to instantiate application com.ClickApp.click.ClickApp: java.lang.ClassNotFoundException: Didn't find class "com.ClickApp.click.ClickApp" on path: DexPathList[[zip file "/data/app/com.ClickApp.click-1.apk"],nativeLibraryDirectories=[/data/app-lib/com.ClickApp.click-1, /vendor/lib, /system/lib]]
at android.app.LoadedApk.makeApplication(LoadedApk.java:524)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4701)
at android.app.ActivityThread.access$1600(ActivityThread.java:148)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1379)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:5473)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:525)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:854)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:670)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.ClassNotFoundException: Didn't find class "com.ClickApp.click.ClickApp" on path: DexPathList[[zip file "/data/app/com.ClickApp.click-1.apk"],nativeLibraryDirectories=[/data/app-lib/com.ClickApp.click-1, /vendor/lib, /system/lib]]
at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:53)
at java.lang.ClassLoader.loadClass(ClassLoader.java:501)
at java.lang.ClassLoader.loadClass(ClassLoader.java:461)
at android.app.Instrumentation.newApplication(Instrumentation.java:975)
at android.app.LoadedApk.makeApplication(LoadedApk.java:519)
... 11 more
java.lang.RuntimeException: Unable to instantiate application com.ClickApp.click.ClickApp: java.lang.ClassNotFoundException: Didn't find class "com.ClickApp.click.ClickApp" on path: DexPathList[[zip file "/data/app/com.ClickApp.click-1.apk"],nativeLibraryDirectories=[/data/app-lib/com.ClickApp.click-1, /vendor/lib, /system/lib]]
at android.app.LoadedApk.makeApplication(LoadedApk.java:524)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4701)
at android.app.ActivityThread.access$1600(ActivityThread.java:148)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1379)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:5473)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:525)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:854)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:670)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.ClassNotFoundException: Didn't find class "com.ClickApp.click.ClickApp" on path: DexPathList[[zip file "/data/app/com.ClickApp.click-1.apk"],nativeLibraryDirectories=[/data/app-lib/com.ClickApp.click-1, /vendor/lib, /system/lib]]
at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:53)
at java.lang.ClassLoader.loadClass(ClassLoader.java:501)
at java.lang.ClassLoader.loadClass(ClassLoader.java:461)
at android.app.Instrumentation.newApplication(Instrumentation.java:975)
at android.app.LoadedApk.makeApplication(LoadedApk.java:519)
... 11 more
cc...@gmail.com
Just got this on a Nexus 5 with 5.0.1 (LRX22C).
First time I'm seeing this myself, during development, as opposed to user reports from Google Play.
The class is there, has been for years and years. Just re-starting the app from its launcher icon (without a reinstall) worked fine, no exception this time.
How in the world can an "operating system" lose track of some of application components?
How in the world can a bug like this go unfixed for so long?
I really hope this report isn't ignored for a couple of years and then marked "obsolete" when Android 6.0 is released.
Please.
The output of "adb bugreport" is attached.
---
01-10 02:06:55.721 E/AndroidRuntime(21610): FATAL EXCEPTION: main
01-10 02:06:55.721 E/AndroidRuntime(21610): Process: org.kman.AquaMail, PID: 21610
01-10 02:06:55.721 E/AndroidRuntime(21610): java.lang.RuntimeException: Unable to instantiate application org.kman.AquaMail.core.AquaMailApplication: java.lang.ClassNotFoundException: Didn't find class "org.kman.AquaMail.core.AquaMailApplication" on path: DexPathList[[],nativeLibraryDirectories=[/vendor/lib, /system/lib]]
01-10 02:06:55.721 E/AndroidRuntime(21610): at android.app.LoadedApk.makeApplication(LoadedApk.java:563)
01-10 02:06:55.721 E/AndroidRuntime(21610): at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4491)
01-10 02:06:55.721 E/AndroidRuntime(21610): at android.app.ActivityThread.access$1500(ActivityThread.java:144)
01-10 02:06:55.721 E/AndroidRuntime(21610): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1339)
01-10 02:06:55.721 E/AndroidRuntime(21610): at android.os.Handler.dispatchMessage(Handler.java:102)
01-10 02:06:55.721 E/AndroidRuntime(21610): at android.os.Looper.loop(Looper.java:135)
01-10 02:06:55.721 E/AndroidRuntime(21610): at android.app.ActivityThread.main(ActivityThread.java:5221)
01-10 02:06:55.721 E/AndroidRuntime(21610): at java.lang.reflect.Method.invoke(Native Method)
01-10 02:06:55.721 E/AndroidRuntime(21610): at java.lang.reflect.Method.invoke(Method.java:372)
01-10 02:06:55.721 E/AndroidRuntime(21610): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:899)
01-10 02:06:55.721 E/AndroidRuntime(21610): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:694)
01-10 02:06:55.721 E/AndroidRuntime(21610): Caused by: java.lang.ClassNotFoundException: Didn't find class "org.kman.AquaMail.core.AquaMailApplication" on path: DexPathList[[],nativeLibraryDirectories=[/vendor/lib, /system/lib]]
01-10 02:06:55.721 E/AndroidRuntime(21610): at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:56)
01-10 02:06:55.721 E/AndroidRuntime(21610): at java.lang.ClassLoader.loadClass(ClassLoader.java:511)
01-10 02:06:55.721 E/AndroidRuntime(21610): at java.lang.ClassLoader.loadClass(ClassLoader.java:469)
01-10 02:06:55.721 E/AndroidRuntime(21610): at android.app.Instrumentation.newApplication(Instrumentation.java:979)
01-10 02:06:55.721 E/AndroidRuntime(21610): at android.app.LoadedApk.makeApplication(LoadedApk.java:558)
01-10 02:06:55.721 E/AndroidRuntime(21610): ... 10 more
01-10 02:06:55.721 E/AndroidRuntime(21610): Suppressed: java.lang.ClassNotFoundException: org.kman.AquaMail.core.AquaMailApplication
01-10 02:06:55.721 E/AndroidRuntime(21610): at java.lang.Class.classForName(Native Method)
01-10 02:06:55.721 E/AndroidRuntime(21610): at java.lang.BootClassLoader.findClass(ClassLoader.java:781)
01-10 02:06:55.721 E/AndroidRuntime(21610): at java.lang.BootClassLoader.loadClass(ClassLoader.java:841)
01-10 02:06:55.721 E/AndroidRuntime(21610): at java.lang.ClassLoader.loadClass(ClassLoader.java:504)
01-10 02:06:55.721 E/AndroidRuntime(21610): ... 13 more
01-10 02:06:55.721 E/AndroidRuntime(21610): Caused by: java.lang.NoClassDefFoundError: Class not found using the boot class loader; no stack available
01-10 02:06:55.728 W/asset ( 740): Asset path /data/app/org.kman.AquaMail-2/base.apk is neither a directory nor file (type=1).
First time I'm seeing this myself, during development, as opposed to user reports from Google Play.
The class is there, has been for years and years. Just re-starting the app from its launcher icon (without a reinstall) worked fine, no exception this time.
How in the world can an "operating system" lose track of some of application components?
How in the world can a bug like this go unfixed for so long?
I really hope this report isn't ignored for a couple of years and then marked "obsolete" when Android 6.0 is released.
Please.
The output of "adb bugreport" is attached.
---
01-10 02:06:55.721 E/AndroidRuntime(21610): FATAL EXCEPTION: main
01-10 02:06:55.721 E/AndroidRuntime(21610): Process: org.kman.AquaMail, PID: 21610
01-10 02:06:55.721 E/AndroidRuntime(21610): java.lang.RuntimeException: Unable to instantiate application org.kman.AquaMail.core.AquaMailApplication: java.lang.ClassNotFoundException: Didn't find class "org.kman.AquaMail.core.AquaMailApplication" on path: DexPathList[[],nativeLibraryDirectories=[/vendor/lib, /system/lib]]
01-10 02:06:55.721 E/AndroidRuntime(21610): at android.app.LoadedApk.makeApplication(LoadedApk.java:563)
01-10 02:06:55.721 E/AndroidRuntime(21610): at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4491)
01-10 02:06:55.721 E/AndroidRuntime(21610): at android.app.ActivityThread.access$1500(ActivityThread.java:144)
01-10 02:06:55.721 E/AndroidRuntime(21610): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1339)
01-10 02:06:55.721 E/AndroidRuntime(21610): at android.os.Handler.dispatchMessage(Handler.java:102)
01-10 02:06:55.721 E/AndroidRuntime(21610): at android.os.Looper.loop(Looper.java:135)
01-10 02:06:55.721 E/AndroidRuntime(21610): at android.app.ActivityThread.main(ActivityThread.java:5221)
01-10 02:06:55.721 E/AndroidRuntime(21610): at java.lang.reflect.Method.invoke(Native Method)
01-10 02:06:55.721 E/AndroidRuntime(21610): at java.lang.reflect.Method.invoke(Method.java:372)
01-10 02:06:55.721 E/AndroidRuntime(21610): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:899)
01-10 02:06:55.721 E/AndroidRuntime(21610): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:694)
01-10 02:06:55.721 E/AndroidRuntime(21610): Caused by: java.lang.ClassNotFoundException: Didn't find class "org.kman.AquaMail.core.AquaMailApplication" on path: DexPathList[[],nativeLibraryDirectories=[/vendor/lib, /system/lib]]
01-10 02:06:55.721 E/AndroidRuntime(21610): at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:56)
01-10 02:06:55.721 E/AndroidRuntime(21610): at java.lang.ClassLoader.loadClass(ClassLoader.java:511)
01-10 02:06:55.721 E/AndroidRuntime(21610): at java.lang.ClassLoader.loadClass(ClassLoader.java:469)
01-10 02:06:55.721 E/AndroidRuntime(21610): at android.app.Instrumentation.newApplication(Instrumentation.java:979)
01-10 02:06:55.721 E/AndroidRuntime(21610): at android.app.LoadedApk.makeApplication(LoadedApk.java:558)
01-10 02:06:55.721 E/AndroidRuntime(21610): ... 10 more
01-10 02:06:55.721 E/AndroidRuntime(21610): Suppressed: java.lang.ClassNotFoundException: org.kman.AquaMail.core.AquaMailApplication
01-10 02:06:55.721 E/AndroidRuntime(21610): at java.lang.Class.classForName(Native Method)
01-10 02:06:55.721 E/AndroidRuntime(21610): at java.lang.BootClassLoader.findClass(ClassLoader.java:781)
01-10 02:06:55.721 E/AndroidRuntime(21610): at java.lang.BootClassLoader.loadClass(ClassLoader.java:841)
01-10 02:06:55.721 E/AndroidRuntime(21610): at java.lang.ClassLoader.loadClass(ClassLoader.java:504)
01-10 02:06:55.721 E/AndroidRuntime(21610): ... 13 more
01-10 02:06:55.721 E/AndroidRuntime(21610): Caused by: java.lang.NoClassDefFoundError: Class not found using the boot class loader; no stack available
01-10 02:06:55.728 W/asset ( 740): Asset path /data/app/org.kman.AquaMail-2/base.apk is neither a directory nor file (type=1).
eb...@gmail.com
Looks like a duplicate of 56296
in...@gmail.com
I'm seeing this too when passing a parcelable in a bundle from the Application context to an Activity. I've solved it by setting the class loader on the parcel before trying to extract the parcelable. For example, in my GlobalState
public class GlobalState extends Application {
...
// _profile is: public class Profile implements Parcelable
// this uses a service to send the profile object in a bundle to
// result receivers in activities
Topics.dispatchProfileUpdated(GlobalState.this, _profile);
...
}
in the receiver I have
parcel.setClassLoader(getContext().getClassLoader());
_profile = parcel.getParcelable(Topics.TOPIC_PROFILE_PARAM_PROFILE);
public class GlobalState extends Application {
...
// _profile is: public class Profile implements Parcelable
// this uses a service to send the profile object in a bundle to
// result receivers in activities
Topics.dispatchProfileUpdated(GlobalState.this, _profile);
...
}
in the receiver I have
parcel.setClassLoader(getContext().getClassLoader());
_profile = parcel.getParcelable(Topics.TOPIC_PROFILE_PARAM_PROFILE);
ya...@gmail.com
Same issue reported on Android 5.0 version, any solution provided by android development team?
ya...@gmail.com
I can reproduce it with almost 100% RR with these steps:
1) Open a screen with map fragment
2) Scroll the map constantly
3) While scrolling, update application (install using adb).
In real life this step happens when automatic update starts
4) Observe the crash "Unable to instantiate application" at android.app.LoadedApk.makeApplication(LoadedApk.java:563)
at android.app.LoadedApk.initializeJavaContextClassLoader(LoadedApk.java:409)
Android 5.1, N5.
Activity manager throws warning:
Force removing ActivityRecord{2175709e u0 <cut>MapActivity t5094}: app died, no saved state
Unable to retrieve gids
android.content.pm.PackageManager$NameNotFoundException:com.asda.android
at android.app.ApplicationPackageManager.getPackageGids(ApplicationPackageManager.java:193)
at com.android.server.am.ActivityManagerService.startProcessLocked(ActivityManagerService.java:2930)
at com.android.server.am.ActivityManagerService.startProcessLocked(ActivityManagerService.java:2883)
at com.android.server.am.ActivityManagerService.startProcessLocked(ActivityManagerService.java:2768)
at com.android.server.am.ActivityStackSupervisor.startSpecificActivityLocked(ActivityStackSupervisor.java:1292)
at com.android.server.am.ActivityStack.resumeTopActivityInnerLocked(ActivityStack.java:1891)
at com.android.server.am.ActivityStack.resumeTopActivityLocked(ActivityStack.java:1455)
at com.android.server.am.ActivityStack.resumeTopActivityLocked(ActivityStack.java:1438)
at com.android.server.am.ActivityStack.finishCurrentActivityLocked(ActivityStack.java:2807)
at com.android.server.am.ActivityStack.finishActivityLocked(ActivityStack.java:2736)
at com.android.server.am.ActivityStack.forceStopPackageLocked(ActivityStack.java:3853)
at com.android.server.am.ActivityStackSupervisor.forceStopPackageLocked(ActivityStackSupervisor.java:2419)
at com.android.server.am.ActivityManagerService.forceStopPackageLocked(ActivityManagerService.java:5659)
at com.android.server.am.ActivityManagerService.access$400(ActivityManagerService.java:238)
at com.android.server.am.ActivityManagerService$MainHandler.handleMessage(ActivityManagerService.java:1556)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:135)
at android.os.HandlerThread.run(HandlerThread.java:61)
at com.android.server.ServiceThread.run(ServiceThread.java:46)
Spurious death for ProcessRecord{15de531 14790:com.asda.android/u0a204 }, curProc for 14790: null
I hope this will help to fix this ancient crash. And yes, it is not "obsolete".
1) Open a screen with map fragment
2) Scroll the map constantly
3) While scrolling, update application (install using adb).
In real life this step happens when automatic update starts
4) Observe the crash "Unable to instantiate application" at android.app.LoadedApk.makeApplication(LoadedApk.java:563)
at android.app.LoadedApk.initializeJavaContextClassLoader(LoadedApk.java:409)
Android 5.1, N5.
Activity manager throws warning:
Force removing ActivityRecord{2175709e u0 <cut>MapActivity t5094}: app died, no saved state
Unable to retrieve gids
android.content.pm.PackageManager$NameNotFoundException:
at android.app.ApplicationPackageManager.getPackageGids(ApplicationPackageManager.java:193)
at com.android.server.am.ActivityManagerService.startProcessLocked(ActivityManagerService.java:2930)
at com.android.server.am.ActivityManagerService.startProcessLocked(ActivityManagerService.java:2883)
at com.android.server.am.ActivityManagerService.startProcessLocked(ActivityManagerService.java:2768)
at com.android.server.am.ActivityStackSupervisor.startSpecificActivityLocked(ActivityStackSupervisor.java:1292)
at com.android.server.am.ActivityStack.resumeTopActivityInnerLocked(ActivityStack.java:1891)
at com.android.server.am.ActivityStack.resumeTopActivityLocked(ActivityStack.java:1455)
at com.android.server.am.ActivityStack.resumeTopActivityLocked(ActivityStack.java:1438)
at com.android.server.am.ActivityStack.finishCurrentActivityLocked(ActivityStack.java:2807)
at com.android.server.am.ActivityStack.finishActivityLocked(ActivityStack.java:2736)
at com.android.server.am.ActivityStack.forceStopPackageLocked(ActivityStack.java:3853)
at com.android.server.am.ActivityStackSupervisor.forceStopPackageLocked(ActivityStackSupervisor.java:2419)
at com.android.server.am.ActivityManagerService.forceStopPackageLocked(ActivityManagerService.java:5659)
at com.android.server.am.ActivityManagerService.access$400(ActivityManagerService.java:238)
at com.android.server.am.ActivityManagerService$MainHandler.handleMessage(ActivityManagerService.java:1556)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:135)
at android.os.HandlerThread.run(HandlerThread.java:61)
at com.android.server.ServiceThread.run(ServiceThread.java:46)
Spurious death for ProcessRecord{15de531 14790:
I hope this will help to fix this ancient crash. And yes, it is not "obsolete".
gl...@gmail.com
There is a new scenario in 5.0+ involving WebView.
Since WebView implementation is now a separate component and gets updates via Play -- it may happen to be in the process of getting updated at the same time as the user is (unknowingly) trying to use WebView in an app.
The result is the app crashing (and of course it's the app, not Android, getting the blame).
I have crash logs from Play Developer Console, and would be happy to post them if needed (if there is any interest... so far, seems like there is none... would be glad to be wrong about it).
Since WebView implementation is now a separate component and gets updates via Play -- it may happen to be in the process of getting updated at the same time as the user is (unknowingly) trying to use WebView in an app.
The result is the app crashing (and of course it's the app, not Android, getting the blame).
I have crash logs from Play Developer Console, and would be happy to post them if needed (if there is any interest... so far, seems like there is none... would be glad to be wrong about it).
yo...@gmail.com
Unbelievable ! Well done GOOGLE!
yo...@gmail.com
Could someone from Google comment on how a bug is marked "Obsolete" when 1) no effort is made to find out if it's still there in 5.0 and 2) there is a comment saying the bug is present in 5.0?
Are all bugs reported against 5.0 and 5.1 now considered "obsolete" because you've got Android M coming up?
Are all bugs reported against 5.0 and 5.1 now considered "obsolete" because you've got Android M coming up?
el...@gmail.com
This is happening for the latest Marshmallow updates on a Nexus 5. Three updates in a row my app has crashed. Android System Webview also doesn't automatically install on any of the phones I've experienced this with following an update, unless it takes days. This is garbage.
gl...@gmail.com
Pretty clear this is a race condition between something starting the app and it getting re-installed. I've seen a logcat around the crash. You can see Android getting a request to start a receiver (although it can happen with other components of course). It spawns the zygote, then tries to load the application class. It tries to open the APK resource, can't find it, then crashes the zygote. While it's technically your app that's crashing, none of your app's code was even running yet.
Here's the code in LoadedApk.java,
try {
java.lang.ClassLoader cl = getClassLoader();
if (!mPackageName.equals("android")) {
initializeJavaContextClassLoader();
}
ContextImpl appContext = ContextImpl.createAppContext(mActivityThread, this);
app = mActivityThread.mInstrumentation.newApplication(
cl, appClass, appContext);
appContext.setOuterContext(app);
} catch (Exception e) {
if (!mActivityThread.mInstrumentation.onException(app, e)) {
throw new RuntimeException(
"Unable to instantiate application " + appClass
+ ": " + e.toString(), e);
}
}
Barring some complex locking between app installation and all of the entry points that start components in your app, I think a "fix" here could be to just silently close the process. What else can you do? Someone asked your app to run, but the code isn't there.
Here's the code in LoadedApk.java,
try {
java.lang.ClassLoader cl = getClassLoader();
if (!mPackageName.equals("android")) {
initializeJavaContextClassLoader();
}
ContextImpl appContext = ContextImpl.createAppContext(mActivityThread, this);
app = mActivityThread.mInstrumentation.newApplication(
cl, appClass, appContext);
appContext.setOuterContext(app);
} catch (Exception e) {
if (!mActivityThread.mInstrumentation.onException(app, e)) {
throw new RuntimeException(
"Unable to instantiate application " + appClass
+ ": " + e.toString(), e);
}
}
Barring some complex locking between app installation and all of the entry points that start components in your app, I think a "fix" here could be to just silently close the process. What else can you do? Someone asked your app to run, but the code isn't there.
gl...@gmail.com
The workaround from
dd...@gmail.com
@commonsware:
the scenario is described here:http://stackoverflow.com/questions/21073136/kitkat-service-is-null-after-exiting-main-activity
and it has been tested on Galaxy Nexus 4.4.2 and Nexus 7 4.4.2 (the same code works perfectly on Android 4.3).
the scenario is described here:
and it has been tested on Galaxy Nexus 4.4.2 and Nexus 7 4.4.2 (the same code works perfectly on Android 4.3).
mu...@gmail.com
Yes, I have the same issue with my app on google play. I had to set " excludeFromRecents="true" ", this way I could avoid the bug. It happens to me on Android 4.1.2, Motorola RAZRi, but not only on this device, my users reported it too.
If the service is running on its own process, why it stops after remove the app from recents ?
My service only crashes after the count up of my AlarmManager, it does not crashe until my alarm trigger. However, my app crashes, after a random time (can be seconds or even hours), it comes back and do not crash anymore. Looks like it restarted "in another context" or something.
If the service is running on its own process, why it stops after remove the app from recents ?
My service only crashes after the count up of my AlarmManager, it does not crashe until my alarm trigger. However, my app crashes, after a random time (can be seconds or even hours), it comes back and do not crash anymore. Looks like it restarted "in another context" or something.
an...@gmail.com
#19, same here, tried running the service in its own process, it gets killed anyway, but after 5 to 50 seconds! Using an alarm to restart the service is thus very unreliable. The service was started as a foreground (with notification) and it doesn't make any difference!
It seems the only alternatives is it use AlarmManager as a keep-alive mechanism, deteriorating this situation even more. While trying to "save memory/battery" with this change and get rid of badly behaving apps, they're only make it worse. How funny!
It seems the only alternatives is it use AlarmManager as a keep-alive mechanism, deteriorating this situation even more. While trying to "save memory/battery" with this change and get rid of badly behaving apps, they're only make it worse. How funny!
km...@gmail.com
My two cents for the above discussion of inconsistent observations between Mr. Murphy and cocouno.
Just ran some tests on a Nexus 5 with stock 4.4.2:
Prerequisites:
- A service with START_FOREGROUND
- An activity
- Some broadcast receivers
- A scheduled alarm manager event (wired to one of those receivers)
- My app has only one process for all components.
Test:
- Run the activity, exit it with Back, swipe away from the recents
Results:
- The background service does not get killed immediately, the process doesn't get killed either
**** However, and this is the really important part ***
The app's process gets killed on the next broadcast from the alarm manager. The broadcast never reaches the app's code, that is, the process is killed *before* broadcast delivery, not after.
As noted before, the service's status bar icon continues to show. This alone, to me, is 200% evidence that this is a bug.
- The next broadcast works properly, creating a new process for the app, and delivering the broadcast.
The interval between the "bad" and the "good" broadcast is of course app-dependent (if there is a next broadcast at all), and in general, can cause an arbitrarily large interval where the app appears to be running (status bar icon) but in fact does not.
- Logcat output:
>>> Swiped the task from recents:
03-04 15:12:13.943 I/KeepAliveService(31936): onTaskRemoved: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10000000 cmp=org.kman.AquaMail/.ui.AccountListActivity }
>>> This is when my alarm's broadcast fired:
03-04 15:15:01.033 I/ActivityManager( 768): Killing 31936:org.kman.AquaMail/u0a80 (adj 0): remove task
03-04 15:16:01.033 W/BroadcastQueue( 768): Timeout of broadcast BroadcastRecord{43881810 u0 org.kman.AquaMail.ALARM_TICK} - receiver=null, started 60002ms ago
03-04 15:16:01.033 W/BroadcastQueue( 768): Receiver during timeout: ResolveInfo{43460008 org.kman.AquaMail/.core.AlarmReceiver m=0x0}
An almost exact issue was present in 4.1.1 (almost a year and a half ago). Here is a relevant discussion on @android-developers:
https://groups.google.com/d/msg/android-developers/LtmA9xbrD5A/a29R5xjKYucJ
More thoughts:
- The system code, since 4.1 or so, appears to try to be more clever than before about picking processes to kill, based on what they do, including broadcast receivers being fired. It appears that this does not work well, making wrong decisions, perhaps because the code considers only one, most recent, event (i.e. the fact that the process also has a foreground service is somehow forgotten when the broadcast is taken into consideration).
- The workaround posted on SO and elsewhere, sends a delayed broadcast with Intent.FLAG_RECEIVER_FOREGROUND inside onTaskRemoved. This, apparently, resets those silly "smarts" in system code.
It should work to add this flag to regular broadcasts used by an app, on the condition that it's added to *all of them*.
And some more:
Google's push for lower memory consumption since 4.1 is leaving behind serious bugs, which not only do not get fixed, but keep getting worse.
GCM should continue to work, and it works fine for Google's own apps, but not all third party apps can use it (e.g. mine is an email app, and has to connect to actual mail servers, not Google's GCM).
And not all apps are, or should be, structured like Google's own.
At the same time, some of Google's own apps stay in memory for long periods of time, making the whole effort look hypocritical. I'm sure that's not the intent, but really, shouldn't these behave better?
Some choice packages from $adb shell ps:
com.google.android.youtube (two processes, never ran YouTube on this device)
com.android.musicfx (never listened to music on this device)
com.google.android.partnersetup (setup? the device was fully set up a month or two ago)
com.google.android.apps.magazines (magazines? I've never viewed any magazines in Google Play)
com.google.android.apps.plus (I don't use G+ on this device)
com.redbend.vdmc (an OTA update checker? why does it keep running?)
Just ran some tests on a Nexus 5 with stock 4.4.2:
Prerequisites:
- A service with START_FOREGROUND
- An activity
- Some broadcast receivers
- A scheduled alarm manager event (wired to one of those receivers)
- My app has only one process for all components.
Test:
- Run the activity, exit it with Back, swipe away from the recents
Results:
- The background service does not get killed immediately, the process doesn't get killed either
**** However, and this is the really important part ***
The app's process gets killed on the next broadcast from the alarm manager. The broadcast never reaches the app's code, that is, the process is killed *before* broadcast delivery, not after.
As noted before, the service's status bar icon continues to show. This alone, to me, is 200% evidence that this is a bug.
- The next broadcast works properly, creating a new process for the app, and delivering the broadcast.
The interval between the "bad" and the "good" broadcast is of course app-dependent (if there is a next broadcast at all), and in general, can cause an arbitrarily large interval where the app appears to be running (status bar icon) but in fact does not.
- Logcat output:
>>> Swiped the task from recents:
03-04 15:12:13.943 I/KeepAliveService(31936): onTaskRemoved: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10000000 cmp=org.kman.AquaMail/.ui.AccountListActivity }
>>> This is when my alarm's broadcast fired:
03-04 15:15:01.033 I/ActivityManager( 768): Killing 31936:org.kman.AquaMail/u0a80 (adj 0): remove task
03-04 15:16:01.033 W/BroadcastQueue( 768): Timeout of broadcast BroadcastRecord{43881810 u0 org.kman.AquaMail.ALARM_TICK} - receiver=null, started 60002ms ago
03-04 15:16:01.033 W/BroadcastQueue( 768): Receiver during timeout: ResolveInfo{43460008 org.kman.AquaMail/.core.AlarmReceiver m=0x0}
An almost exact issue was present in 4.1.1 (almost a year and a half ago). Here is a relevant discussion on @android-developers:
More thoughts:
- The system code, since 4.1 or so, appears to try to be more clever than before about picking processes to kill, based on what they do, including broadcast receivers being fired. It appears that this does not work well, making wrong decisions, perhaps because the code considers only one, most recent, event (i.e. the fact that the process also has a foreground service is somehow forgotten when the broadcast is taken into consideration).
- The workaround posted on SO and elsewhere, sends a delayed broadcast with Intent.FLAG_RECEIVER_FOREGROUND inside onTaskRemoved. This, apparently, resets those silly "smarts" in system code.
It should work to add this flag to regular broadcasts used by an app, on the condition that it's added to *all of them*.
And some more:
Google's push for lower memory consumption since 4.1 is leaving behind serious bugs, which not only do not get fixed, but keep getting worse.
GCM should continue to work, and it works fine for Google's own apps, but not all third party apps can use it (e.g. mine is an email app, and has to connect to actual mail servers, not Google's GCM).
And not all apps are, or should be, structured like Google's own.
At the same time, some of Google's own apps stay in memory for long periods of time, making the whole effort look hypocritical. I'm sure that's not the intent, but really, shouldn't these behave better?
Some choice packages from $adb shell ps:
com.android.musicfx (never listened to music on this device)
com.google.android.partnersetup (setup? the device was fully set up a month or two ago)
com.google.android.apps.magazines (magazines? I've never viewed any magazines in Google Play)
com.google.android.apps.plus (I don't use G+ on this device)
com.redbend.vdmc (an OTA update checker? why does it keep running?)
an...@gmail.com
The issue is much more complex than you think and there's no inconsistencies.
Running a service as foreground prevents the whole process/service from being killed, but only if service runs in the same process.
However the process is marked as "remove task" and the next non foreground broadcast that is received by the process will get the process killed. Make your broadcast foreground and the process won't be killed! However for those using intentfilters with SCREEN_ON/OFF are out of luck as those filters creates background broadcast and get the app killed, after the broadcast is handled!
The only inconsistencies where present until users admitted there are obvious bugs, noticeably the icon remaining in the status bar, the OS listing the service as still running while the process hosting it is nowhere to be found, etc...
Can't agree more about Google's own apps using sync and escaping this entirely, probably on purpose. However they obviously behave much more badly than any other apps as you point out, they run even if they were never used, ever.
Running a service as foreground prevents the whole process/service from being killed, but only if service runs in the same process.
However the process is marked as "remove task" and the next non foreground broadcast that is received by the process will get the process killed. Make your broadcast foreground and the process won't be killed! However for those using intentfilters with SCREEN_ON/OFF are out of luck as those filters creates background broadcast and get the app killed, after the broadcast is handled!
The only inconsistencies where present until users admitted there are obvious bugs, noticeably the icon remaining in the status bar, the OS listing the service as still running while the process hosting it is nowhere to be found, etc...
Can't agree more about Google's own apps using sync and escaping this entirely, probably on purpose. However they obviously behave much more badly than any other apps as you point out, they run even if they were never used, ever.
di...@gmail.com
Is there a way to log all broadcasts? Because my app is getting killed and I don't seem to be receiving any broadcasts, and my service is started with startForeground and runs in the same process.
km...@gmail.com
@androtu (#23): yes, a non-foreground broadcast causes process death.
This is an inconsistency in system code somewhere -- the process still has a foreground service, and this should be taken into consideration when deciding how important the process is (but is not).
I ran some tests with adding Intent.FLAG_RECEIVER_FOREGROUND to all my broadcasts, even those set in AlarmManager, and it helped somewhat, but there are still scenarios causing unexpected process kill:
- Broadcasts sent by the system (e.g. ConnectivityManager, etc.) which I can't control
- This is a weird one: updating a home screen widget (!!!)
This is an inconsistency in system code somewhere -- the process still has a foreground service, and this should be taken into consideration when deciding how important the process is (but is not).
I ran some tests with adding Intent.FLAG_RECEIVER_FOREGROUND to all my broadcasts, even those set in AlarmManager, and it helped somewhat, but there are still scenarios causing unexpected process kill:
- Broadcasts sent by the system (e.g. ConnectivityManager, etc.) which I can't control
- This is a weird one: updating a home screen widget (!!!)
cc...@gmail.com
Another weird one is receiving SCREEN_ON/SCREEN_OFF events, many
IntentFilter can cause this.
To cope with this, when my service receives a onRemoveTask keeps a flag
about it, then on every onReceive of such broadcast receiver I check for
that flag and set an alarm to auto-restart the service.
Looking at the source code it seems (hopefully) this non-foreground
broadcast only affect swiped-away task apps, but the OS will not kill the
apps with foreground services.
That's a real mess, and this buggy version has been out there for month now
and is spreading like a virus!
What do we do once it's fixed in the OS? Keep those dirty work-around for
API 19 only hoping for the best? And what if they release 4.4.3 under API19,
those dirty workaround are just wasting CPU cycles and may cause more harm
than good in the end.
-----Message d'origine-----
De�: android@googlecode.com [mailto:android@googlecode.com]
Envoy�: jeudi 13 mars 2014 12:02
��: ccounotte@gmail.com
Objet�: Re:
permanently kills app (like force-stop) even though it's running background
services!
IntentFilter can cause this.
To cope with this, when my service receives a onRemoveTask keeps a flag
about it, then on every onReceive of such broadcast receiver I check for
that flag and set an alarm to auto-restart the service.
Looking at the source code it seems (hopefully) this non-foreground
broadcast only affect swiped-away task apps, but the OS will not kill the
apps with foreground services.
That's a real mess, and this buggy version has been out there for month now
and is spreading like a virus!
What do we do once it's fixed in the OS? Keep those dirty work-around for
API 19 only hoping for the best? And what if they release 4.4.3 under API19,
those dirty workaround are just wasting CPU cycles and may cause more harm
than good in the end.
-----Message d'origine-----
De�: android@googlecode.com [mailto:android@googlecode.com]
Envoy�: jeudi 13 mars 2014 12:02
��: ccounotte@gmail.com
Objet�: Re:
permanently kills app (like force-stop) even though it's running background
services!
en...@google.com
co...@gmail.com
me...@gmail.com
I think I'm having the same issue except my reproduction of the bug is much easier. I'm seeing this on a Nexus 5 running Android 5.0.1.
Here is my StackOverflow question with details on how to reproduce this.
http://stackoverflow.com/questions/29221149/foreground-service-getting-killed-when-pressing-home-button
Here is my StackOverflow question with details on how to reproduce this.
lj...@gmail.com
i found perfect workround
service killed because no activity in that process had binded it，i think it's a android bug.now you can do like below:
start an empty activity which run in service process, do bindservice then finish immediately.now your service process won't killed when user swipe away your app
class NannyActivity extends Activity {
public void onCreate(Bundle savedInstanceState) {
//must run in servce process,must bind that service
bindservice(xxxxx);
finish();
}
}
service killed because no activity in that process had binded it，i think it's a android bug.now you can do like below:
start an empty activity which run in service process, do bindservice then finish immediately.now your service process won't killed when user swipe away your app
class NannyActivity extends Activity {
public void onCreate(Bundle savedInstanceState) {
//must run in servce process,must bind that service
bindservice(xxxxx);
finish();
}
}
mi...@naprvyraz.sk
#23, #26: Do you have a code example for this? I'm able to reproduce it with the PendingIntent way but not with plain BroadcastReceiver + ACTION_SCREEN_{ON,OFF}. If possible, please include Android version, too.
Description
Steps to reproduce:
- Take any app that have a UI and runs a background service (with stopWithTask="false").
- Open the UI, go back to launcher, then remove the task/app from recent task list
What happens:
- App is permanently terminated along with any of its services.
What I believe is the correct behavior:
- App UI is terminated, service remains functional.
On Android 4.0 up-to Android 4.3, the "correct" behavior can be verified, eg the app UI is terminated, services keep running (or restarted?).
IMO, the following documentation confirms the "correct" behavior I expect:
public static final int stopWithTask
If set to true, this service with be automatically stopped when the user remove a task rooted in an activity owned by the application. The default is false.
public void onTaskRemoved (Intent rootIntent)
This is called if the service is currently running and the user has removed a task that comes from the service's application. If you have set ServiceInfo.FLAG_STOP_WITH_TASK then you will not receive this callback; instead, the service will simply be stopped.
Since Android 4.4, IMO the stopWithTask flag is now completely ineffective. Or is this intentional?
I find this new behavior highly confusing for end-users: the recent task list is turned into a task killer force-stopping apps, but is not able to stop apps having started on boot except if end-user first starts the apps he/she wants to kill! Can't be any worse IMO.
So now we have 2 ways of force-stopping apps depending on whether we started them or not, from the recent task list or from the Applications, Installed Apps, Force-Stop button. Even more confusing IMO.