16

I have integrated the in-app updates feature by Google Play Core library using this link.

I am using immediate update option because we make various critical bug fixes regularly which are important to update.

Here are the cases when app doesn't crash and updates app successfully and when it crashes.

  1. Click 'Update' button when app update is available and let the update to finish properly without interrupting it in between - App Updated successfully.
  2. Click 'Update' button, update starts to download, but user cancels update in middle by pressing 'x' button present after 'Update Download progress bar' - App Update canceled.
  3. Try opening app again, it crashes with following error.

Fatal Exception: java.lang.RuntimeException java.lang.reflect.InvocationTargetException com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:586) com.android.internal.os.ZygoteInit.main (ZygoteInit.java:942) Caused by java.lang.reflect.InvocationTargetException java.lang.reflect.Method.invoke (Method.java) com.android.internal.os.ZygoteInit.main (ZygoteInit.java:942) Caused by android.content.IntentSender$SendIntentException android.app.Activity.startIntentSenderForResultInner (Activity.java:5019) com.google.android.play.core.appupdate.b.startUpdateFlowForResult (Unknown Source:5) co.behtarinternal.app.menu.MenuActivity$checkForAppUpdate$1.onSuccess (MenuActivity.kt:239) co.behtarinternal.app.menu.MenuActivity$checkForAppUpdate$1.onSuccess (MenuActivity.kt:43) com.google.android.play.core.tasks.e.run (Unknown Source:27) com.android.internal.os.ZygoteInit.main (ZygoteInit.java:942)

I have also referred to this question and its answer, but cannot understand how this solution can be implemented.

I have searched a lot everywhere, but didn't find any feasible solution related to this problem.

If any of you out there have faced a similar issue, and your solution worked, do help me.

Divya Gupta
  • 494
  • 8
  • 24

1 Answers1

7

From what I have understand, you are trying to use the same instance of the AppUpdateInfo somewhere, where its Intent is a rather PendingIntent that you are trying to use multiple times. Since a PendingIntent can be used only once, it throws the exception. To solve this I am guessing you have an option.

If you are able to reproduce this bug locally, call startUpdateFlowForResult() in a try-catch method and try to catch IntentSender$SendIntentException, or InvocationTargetException. If the exception is catched, that means the PendingIntent is used already. Assuming that your checkUpdates() method can be used recursively, call checkUpdates() again, which should create a new AppUpdateManager instance and start the lifecycle again, which will result in a new, fresh AppUpdateInfo as a result, hence the new PendingIntent that should let you open the app update popup again.

Edit: I'm not sure but what happens when onResume code executes again? Like, checkForUpdates is called but you are also replacing the mAppUpdateManager in onResume call, by calling AppUpdateManager.getInstance(this). So, it is a possibility that the mAppUpdateManager.appUpdateInfo might not belong to the newly assigned mAppUpdateManager in onResume, since on application startup both onCreate and onResume is called. Hence, the object itself may not belong to the AppUpdateManager itself.

A solution might be using two different managers, however I think the mechanism itself will return a singleton which makes them both same (maybe?) anyway, you need to check the address endpoints while in debug mode. The debug object should look like AppUpdateManager@2b62aa, check if the managers are different or not. If they become different as I predict, your problem should be resolved.

Furkan Yurdakul
  • 2,801
  • 1
  • 15
  • 37
  • I will try this method and will tell whether this resolved the bug or not. – Divya Gupta Feb 06 '20 at 07:30
  • 2
    The problem is that, this bug doesn't occur frequently, and not in testing time, it occurs only when I make an update live and users try to download it via in app update. And at that time, this bug occurs for every update which different users do. So it can be viewed only via Crashlytics logs, not locally – Divya Gupta Feb 06 '20 at 07:45
  • I see. I guess releasing the app with lower percentage and seeing the results remotely is the only option then. Or, you can try beta testing and see if it works. – Furkan Yurdakul Feb 06 '20 at 08:00
  • Sure, will try that – Divya Gupta Feb 07 '20 at 09:02
  • Actually, what I am doing right now is that, I am creating a new instance of `AppUpdateManager` everytime the `checkUpdates()` method execution is started, so I guess that will give me a new `AppUpdateInfo` instance everytime `checkUpdates()` method is called right? – Divya Gupta Feb 07 '20 at 09:42
  • If it is possible can you share the source code of this process? I'm unable to deduce the problem here just by guessing. Maybe if I see the code I can give a better answer. – Furkan Yurdakul Feb 07 '20 at 10:39
  • Sure, will send you the gist link in a while – Divya Gupta Feb 07 '20 at 11:46
  • Here is the gist https://gist.github.com/Divya0319/dd5a2a47d92106a6ac1bedd7d7840482 – Divya Gupta Feb 07 '20 at 12:04
  • Edited the answer, please check. – Furkan Yurdakul Feb 07 '20 at 13:39
  • App update managers are same when checkUpdates is called twice. What to do now? – Rahul Dec 13 '22 at 11:31
  • Did creating a new app update manager every time solve it for you? – Filippo Vigani Mar 08 '23 at 11:11