The infamous Bump service crash, some workarounds, and a plea for resolution from the Bump people!
351 views
Skip to first unread message
hi.f...@gmail.com
May 15, 2013, 5:50:05 PM5/15/13
to bump-api...@googlegroups.com
I've been developing a prototype app using the Bump API for Android (3.0 Beta 4, of course), and like many others, have experienced crashing and poor reliability of the Bump service. The app has been built against SDK 15 (4.0.3) and has had the same results on a Galaxy Nexus with 4.2.1 and a Galaxy S3 4.1.1.
The problem is that by following the proper service binding lifecycle (Launch -> bindService() & api.configure(), Exit -> unbindService()), it's only a matter of time before an instance of the app results in the crashing of the Bump service with Signal 11 SIGSEGV (like many others have experienced).
Understand this: The BumpTest app that you provide exhibits the exact same behaviour, so this problem is not due to anything specific to my/our applications! It is inherent to your service library.
It took me days (weeks?) of messing around to determine exactly what was and wasn't triggering this behaviour, and I've isolated it and determined 2 workarounds that allow the app to be run many times without the service crashing.
Workarounds:
1. Retain service binding and API configuration between runs
As we know, the Android OS usually keeps the process used to run an app alive between runs of the app and reuses it for subsequent runs. A static global singleton is used to hold the IBumpAPI binding. On first initializing run, the service is bound (bindService()) and the API is configured (<IBumpAPI>.configure()). When the app is destroyed, we do not unbind the service. On subsequent runs, the IBumpAPI binding is reused, without rebinding (if you do call bindService(), you'll see that your ServiceConnection's onServiceConnected() callback gets passed an IBinder that's equal to the one we already received the first time), and the API is not configured again.
Bingo. The service seems to stay alive without crashing nearly indefinitely, across countless launches of the app.
This workaround is clearly a terrible misuse of the Android application lifecycle (and should elicit fear in anyone reading this), but it does seem to work well enough to deal with the flaw in the Bump service. One can presume that it's multiple bindings to a single persistent loaded Bump service library that are triggering the crash. (I notice that the libandroid-api.so library gets reused between runs and doesn't get reloaded into the app process, and wonder if this fact is at the core of the problem, but I certainly don't know enough about this kind of system level Android/Dalvik Java VM stuff……)
2. Force app process deletion so each run has a fresh initialized state
I discovered that turning the Android developer option for Background Processes to 0 also fixed this problem. By having each run of the app receive a new process and thus a fresh initialization of every component, I could run the app an infinite number of times and never experience the crashed Bump service. This was the revelation that made the whole root of the problem clear in the first place.
So, I added "android.os.Process.killProcess(android.os.Process.myPid());" to the end of my onDestroy() method instead of using the phone's developer background process option, and this achieves the same result. This is clearly the more desirable workaround to this problem of the two… except, of course, for the fact that this is still also a clear misuse of the Android OS API and probably shouldn't even be considered for a production release app...
So then, these are some solid facts describing your service crashing and some conditions that are related to it. Can you Bump folks PLEASE address this issue of your service crashing that MANY people are experiencing??!! There is a pile of evidence that your service is crashing on Android, including the fact that your very own BumpTest app is afflicted by this problem, and yet you haven't released a bugfix since API 3.0 Beta 4 over A YEAR ago! We're very frustrated with trying to develop apps using a faulty API.
If there's any other info I can provide, please ask and I'll definitely comply.
Thank you in advance for dealing with this incredibly CRITICAL issue!
Ryan Wrubleski
The problem is that by following the proper service binding lifecycle (Launch -> bindService() & api.configure(), Exit -> unbindService()), it's only a matter of time before an instance of the app results in the crashing of the Bump service with Signal 11 SIGSEGV (like many others have experienced).
Understand this: The BumpTest app that you provide exhibits the exact same behaviour, so this problem is not due to anything specific to my/our applications! It is inherent to your service library.
It took me days (weeks?) of messing around to determine exactly what was and wasn't triggering this behaviour, and I've isolated it and determined 2 workarounds that allow the app to be run many times without the service crashing.
Workarounds:
1. Retain service binding and API configuration between runs
As we know, the Android OS usually keeps the process used to run an app alive between runs of the app and reuses it for subsequent runs. A static global singleton is used to hold the IBumpAPI binding. On first initializing run, the service is bound (bindService()) and the API is configured (<IBumpAPI>.configure()). When the app is destroyed, we do not unbind the service. On subsequent runs, the IBumpAPI binding is reused, without rebinding (if you do call bindService(), you'll see that your ServiceConnection's onServiceConnected() callback gets passed an IBinder that's equal to the one we already received the first time), and the API is not configured again.
Bingo. The service seems to stay alive without crashing nearly indefinitely, across countless launches of the app.
This workaround is clearly a terrible misuse of the Android application lifecycle (and should elicit fear in anyone reading this), but it does seem to work well enough to deal with the flaw in the Bump service. One can presume that it's multiple bindings to a single persistent loaded Bump service library that are triggering the crash. (I notice that the libandroid-api.so library gets reused between runs and doesn't get reloaded into the app process, and wonder if this fact is at the core of the problem, but I certainly don't know enough about this kind of system level Android/Dalvik Java VM stuff……)
2. Force app process deletion so each run has a fresh initialized state
I discovered that turning the Android developer option for Background Processes to 0 also fixed this problem. By having each run of the app receive a new process and thus a fresh initialization of every component, I could run the app an infinite number of times and never experience the crashed Bump service. This was the revelation that made the whole root of the problem clear in the first place.
So, I added "android.os.Process.killProcess(android.os.Process.myPid());" to the end of my onDestroy() method instead of using the phone's developer background process option, and this achieves the same result. This is clearly the more desirable workaround to this problem of the two… except, of course, for the fact that this is still also a clear misuse of the Android OS API and probably shouldn't even be considered for a production release app...
So then, these are some solid facts describing your service crashing and some conditions that are related to it. Can you Bump folks PLEASE address this issue of your service crashing that MANY people are experiencing??!! There is a pile of evidence that your service is crashing on Android, including the fact that your very own BumpTest app is afflicted by this problem, and yet you haven't released a bugfix since API 3.0 Beta 4 over A YEAR ago! We're very frustrated with trying to develop apps using a faulty API.
If there's any other info I can provide, please ask and I'll definitely comply.
Thank you in advance for dealing with this incredibly CRITICAL issue!
Ryan Wrubleski
Michael
May 17, 2013, 11:41:35 AM5/17/13
to bump-api...@googlegroups.com
Hi Ryan,
This is a really excellent explanation. From my investigation, I agree with you on the cause and fix of the problem. I am currently using workaround #1 by subclassing Application, and storing IBumpAPI there. It no longer crashes, but Bump still becomes unresponsive. I've yet to figure out why. Workaround #2 is, as you said, not a real option for us.
Another issue is that if you have multiple apps using Bump API, even with workaround #1 - if Bump is loaded for App A and is put into the background, and App B in the foreground loads Bump, it still causes bump for App A.
I have also noticed all these issues with the BumpTest app.
Mr. Greaney - I'm very disappointed in the Bump API on the Android side. It would be a great product if it worked, but it seems like it doesn't. To be honest, if we don't come up with a resolution soon we may have to drop Bump altogether...Please fix this issue as soon as you can.
Best,
Michael
Dmitri Livotov
May 18, 2013, 4:11:45 AM5/18/13
to bump-api...@googlegroups.com
Hi guys,
to me it looks like that bump people completely dropped off any support for their product. I was writing here many times without any success.
John Barker
May 18, 2013, 4:17:15 AM5/18/13
to bump-api...@googlegroups.com
Yea it does seem that way. Maybe they are just focusing on the actual Bump app as a file sharing platform, rather than the api for other devs. Never mind.
On 18 May 2013 09:11, "Dmitri Livotov" <dmi...@livotov.eu> wrote:
Hi guys,
to me it looks like that bump people completely dropped off any support for their product. I was writing here many times without any success.
--
You received this message because you are subscribed to the Google Groups "bump-api-android" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bump-api-andro...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
hi.f...@gmail.com
May 21, 2013, 1:51:39 PM5/21/13
to bump-api...@googlegroups.com
Hey Michael,
Thanks for the reply. I'm "glad" to hear that my analysis of the situation holds up to scrutiny and that others are experiencing and dealing with the same issues (I'm certainly not glad, but you know what I mean...).
And you're right: the service crashing is only one issue; there's another huge issue surrounding the robustness of the service and how it's often unpredictably unresponsive. There are issues pertaining to the service being unavailable as the API fails to connect and call BumpAPIIntents.CONNECTED, and then there are issues where everything appears to be functional but Bump event attempts that should work suddenly fail to match and won't match again until the app's relaunced, some time has passed, or a magical fairy sneezes at a certain pitch...
I had no idea about your situation with multiple different concurrent apps not working properly, but that doesn't surprise me in the least now given my skepticism around this platform...
I focused on the service crashing in my first post, as opposed to the other reliability issues, because that was something I could illuminate and quantify and I figured that would be a perfect opportunity for the Bump folks to step up and address the quantifiable issue and give us some insight into when fixes for the issue could be expected. I had my doubts that anything was going to come of that, since I've seen numerous other people's problems be ignored for quite some time, but I had the responsiblity to myself and my employer to try. Well, so far no response...
It's sad that we're not getting any response from Bump, and this is probably the tipping point here. We're in the same situation as you are. The service doesn't work well enough on Android, and we're probably going to be have to drop our attempts to develop our app using Bump. I'm still hoping things will change, but this totally non-existent communication and support sure seems like proof of abandonment of the API.
Thanks for the reply. I'm "glad" to hear that my analysis of the situation holds up to scrutiny and that others are experiencing and dealing with the same issues (I'm certainly not glad, but you know what I mean...).
And you're right: the service crashing is only one issue; there's another huge issue surrounding the robustness of the service and how it's often unpredictably unresponsive. There are issues pertaining to the service being unavailable as the API fails to connect and call BumpAPIIntents.CONNECTED, and then there are issues where everything appears to be functional but Bump event attempts that should work suddenly fail to match and won't match again until the app's relaunced, some time has passed, or a magical fairy sneezes at a certain pitch...
I had no idea about your situation with multiple different concurrent apps not working properly, but that doesn't surprise me in the least now given my skepticism around this platform...
I focused on the service crashing in my first post, as opposed to the other reliability issues, because that was something I could illuminate and quantify and I figured that would be a perfect opportunity for the Bump folks to step up and address the quantifiable issue and give us some insight into when fixes for the issue could be expected. I had my doubts that anything was going to come of that, since I've seen numerous other people's problems be ignored for quite some time, but I had the responsiblity to myself and my employer to try. Well, so far no response...
It's sad that we're not getting any response from Bump, and this is probably the tipping point here. We're in the same situation as you are. The service doesn't work well enough on Android, and we're probably going to be have to drop our attempts to develop our app using Bump. I'm still hoping things will change, but this totally non-existent communication and support sure seems like proof of abandonment of the API.
Thomas Greany
May 21, 2013, 7:25:32 PM5/21/13
to bump-api...@googlegroups.com
Hey everyone,
Sorry for the delay on this. I am responsible for the development and
support of both our iOS and Android APIs, and also contribute quite a
lot to the Bump iOS app, where I've spent most of my time lately.
We're a small startup with a lot to juggle, but we want our APIs to be
rock solid and easy to use.
I've pushed a potential fix to a branch on the github project; please
let me know if this behaves better for you. Any stack traces or logs
that you could send in would be great if not.
https://github.com/bumptech/bump-api-android/tree/beta5
Tom
Sorry for the delay on this. I am responsible for the development and
support of both our iOS and Android APIs, and also contribute quite a
lot to the Bump iOS app, where I've spent most of my time lately.
We're a small startup with a lot to juggle, but we want our APIs to be
rock solid and easy to use.
I've pushed a potential fix to a branch on the github project; please
let me know if this behaves better for you. Any stack traces or logs
that you could send in would be great if not.
https://github.com/bumptech/bump-api-android/tree/beta5
Tom
Thomas Greany
May 21, 2013, 7:28:22 PM5/21/13
to bump-api...@googlegroups.com
(If you've added the api as a submodule, or still have its .git
folder, you should be able to run the following to try it:)
git fetch && git checkout -b beta5 origin/beta5
folder, you should be able to run the following to try it:)
git fetch && git checkout -b beta5 origin/beta5
John Barker
May 21, 2013, 7:41:04 PM5/21/13
to bump-api...@googlegroups.com
Thanks for the reply! I will give this a test when I next get a chance.
hi.f...@gmail.com
May 23, 2013, 1:45:01 PM5/23/13
to bump-api...@googlegroups.com
Hi Tom,
I'm pleasantly surprised to hear back from you and relieved to get a favorable answer to the question of Bump's commitment and support of its API, so thanks!
Unfortunately this new version of your library had no effect. The service still crashes with a SIGSEGV/SEGV_MAPERR, using the BumpTest app and my own app, on the 2 different phones/OSes I described previously, built against SDKs 15, 16, and 17, with and without the Bump app installed on the device, etc.
It's pretty hard to understand how something that is so consistently reproducible and unavoidable is something that you're having such a difficulty remedying... Are you not seeing these same results yourself??
May I ask what devices and OSes you're testing on, which phone Developer Options you have enabled, which platform/IDE you're developing on, etc?
What kind of logs and stack traces do you want to see? I can send you the logs, but they're just showing the same thing that others have posted numerous times here and on StackOverflow in relation to this issue...
Ryan
I'm pleasantly surprised to hear back from you and relieved to get a favorable answer to the question of Bump's commitment and support of its API, so thanks!
Unfortunately this new version of your library had no effect. The service still crashes with a SIGSEGV/SEGV_MAPERR, using the BumpTest app and my own app, on the 2 different phones/OSes I described previously, built against SDKs 15, 16, and 17, with and without the Bump app installed on the device, etc.
It's pretty hard to understand how something that is so consistently reproducible and unavoidable is something that you're having such a difficulty remedying... Are you not seeing these same results yourself??
May I ask what devices and OSes you're testing on, which phone Developer Options you have enabled, which platform/IDE you're developing on, etc?
What kind of logs and stack traces do you want to see? I can send you the logs, but they're just showing the same thing that others have posted numerous times here and on StackOverflow in relation to this issue...
Ryan
Avinash Sharma
May 28, 2013, 9:57:48 AM5/28/13
to bump-api...@googlegroups.com
Hey Tom,
I used your new bump api and got this log when i bump for the second time in my application. In OnResume Method I have enable bumping and onDestroy method I have dIsabled bumping. But i got this when i tried for second time.
I have tried and used one global application variable that will not allow to configure it again. But no luck.
Following is log :
05-28 19:14:05.613: W/System.err(17203): android.os.DeadObjectException
05-28 19:14:05.623: W/System.err(17203): at android.os.BinderProxy.transact(Native Method)
05-28 19:14:05.623: W/System.err(17203): at com.bump.api.IBumpAPI$Stub$Proxy.enableBumping(IBumpAPI.java:182)
05-28 19:14:05.623: W/System.err(17203): at com.socialapp.droid.BumpTest.onResume(BumpTest.java:338)
05-28 19:14:05.623: W/System.err(17203): at android.app.Instrumentation.callActivityOnResume(Instrumentation.java:1236)
05-28 19:14:05.623: W/System.err(17203): at android.app.Activity.performResume(Activity.java:4620)
05-28 19:14:05.623: W/System.err(17203): at android.app.ActivityThread.performResumeActivity(ActivityThread.java:2807)
05-28 19:14:05.623: W/System.err(17203): at android.app.ActivityThread.handleResumeActivity(ActivityThread.java:2862)
05-28 19:14:05.623: W/System.err(17203): at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2245)
05-28 19:14:05.623: W/System.err(17203): at android.app.ActivityThread.access$600(ActivityThread.java:139)
05-28 19:14:05.633: W/System.err(17203): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1262)
05-28 19:14:05.633: W/System.err(17203): at android.os.Handler.dispatchMessage(Handler.java:99)
05-28 19:14:05.633: W/System.err(17203): at android.os.Looper.loop(Looper.java:156)
05-28 19:14:05.633: W/System.err(17203): at android.app.ActivityThread.main(ActivityThread.java:4987)
05-28 19:14:05.633: W/System.err(17203): at java.lang.reflect.Method.invokeNative(Native Method)
05-28 19:14:05.643: W/System.err(17203): at java.lang.reflect.Method.invoke(Method.java:511)
05-28 19:14:05.643: W/System.err(17203): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784)
05-28 19:14:05.643: W/System.err(17203): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551)
05-28 19:14:05.643: W/System.err(17203): at dalvik.system.NativeStart.main(Native Method)
Waiting for your reply !!
Thanks,
Avinash
I used your new bump api and got this log when i bump for the second time in my application. In OnResume Method I have enable bumping and onDestroy method I have dIsabled bumping. But i got this when i tried for second time.
I have tried and used one global application variable that will not allow to configure it again. But no luck.
Following is log :
05-28 19:14:05.613: W/System.err(17203): android.os.DeadObjectException
05-28 19:14:05.623: W/System.err(17203): at android.os.BinderProxy.transact(Native Method)
05-28 19:14:05.623: W/System.err(17203): at com.bump.api.IBumpAPI$Stub$Proxy.enableBumping(IBumpAPI.java:182)
05-28 19:14:05.623: W/System.err(17203): at com.socialapp.droid.BumpTest.onResume(BumpTest.java:338)
05-28 19:14:05.623: W/System.err(17203): at android.app.Instrumentation.callActivityOnResume(Instrumentation.java:1236)
05-28 19:14:05.623: W/System.err(17203): at android.app.Activity.performResume(Activity.java:4620)
05-28 19:14:05.623: W/System.err(17203): at android.app.ActivityThread.performResumeActivity(ActivityThread.java:2807)
05-28 19:14:05.623: W/System.err(17203): at android.app.ActivityThread.handleResumeActivity(ActivityThread.java:2862)
05-28 19:14:05.623: W/System.err(17203): at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2245)
05-28 19:14:05.623: W/System.err(17203): at android.app.ActivityThread.access$600(ActivityThread.java:139)
05-28 19:14:05.633: W/System.err(17203): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1262)
05-28 19:14:05.633: W/System.err(17203): at android.os.Handler.dispatchMessage(Handler.java:99)
05-28 19:14:05.633: W/System.err(17203): at android.os.Looper.loop(Looper.java:156)
05-28 19:14:05.633: W/System.err(17203): at android.app.ActivityThread.main(ActivityThread.java:4987)
05-28 19:14:05.633: W/System.err(17203): at java.lang.reflect.Method.invokeNative(Native Method)
05-28 19:14:05.643: W/System.err(17203): at java.lang.reflect.Method.invoke(Method.java:511)
05-28 19:14:05.643: W/System.err(17203): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784)
05-28 19:14:05.643: W/System.err(17203): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551)
05-28 19:14:05.643: W/System.err(17203): at dalvik.system.NativeStart.main(Native Method)
Waiting for your reply !!
Thanks,
Avinash
Avinash Sharma
May 30, 2013, 1:17:54 PM5/30/13
to bump-api...@googlegroups.com
Thomas Greany
May 30, 2013, 2:05:23 PM5/30/13
to bump-api...@googlegroups.com
Thanks, Avinash for the report. I'm hoping to get another build out in
the next few days.
the next few days.
Avinash Sharma
Jun 3, 2013, 2:34:55 AM6/3/13
to bump-api...@googlegroups.com
Hey Tom,
That will be a great help. Please update here after releasing.
Thanks,
Avinash
That will be a great help. Please update here after releasing.
Thanks,
Avinash
mi...@twistedpairproductions.com
Jun 12, 2013, 11:31:09 PM6/12/13
to bump-api...@googlegroups.com
OK Bump people - No NFC on iPhone - its official! Let's get these Android issues worked out so we can build apps using your service. You're the only cross-platform game in town. PLEASE take advantage of this!! FIX your api. We're totally prepared to provide any logs, help, suggestions - whatever you need. Ask if you need. But please let's get this fixed.
Mike M
Juan E. Zamora
Jul 3, 2013, 2:18:11 PM7/3/13
to bump-api...@googlegroups.com
Tom, what about Avinash problem??? I have the same error and its very critical for me!! last week it runs!
Please help us!
thanks!
Please help us!
thanks!
mi...@twistedpairproductions.com
Jul 23, 2013, 1:47:14 PM7/23/13
to bump-api...@googlegroups.com
Anything yet guys???
Avinash Sharma
Jul 25, 2013, 10:17:33 AM7/25/13
to bump-api...@googlegroups.com
Hey Mike M
My problem with android bump api is not yet resolved, any hopes when this problem will resolved ?
Juan was also asking with you but you did not replyed to him. Please atleast provide some idea when can this be resolved.
Best Regards,
Avinash
My problem with android bump api is not yet resolved, any hopes when this problem will resolved ?
Juan was also asking with you but you did not replyed to him. Please atleast provide some idea when can this be resolved.
Best Regards,
Avinash
Vincent Fletcher
Sep 24, 2013, 11:10:50 PM9/24/13
to bump-api...@googlegroups.com
Hello.
Has there been any update to this issue?
We are wanting to incorporate the Bump Android API into our application however reading this has left me waiting for the issue to be resolved before proceeding...
We are wanting to incorporate the Bump Android API into our application however reading this has left me waiting for the issue to be resolved before proceeding...
Reply all
Reply to author
Forward
0 new messages