Closed simonnorberg closed 5 years ago
I think you are completely right that I/we missed that scenario. I like the way you're doing it here, but I think you have to surround the thing in a try/catch-ignore here, in case the user did get an SMS and it was unregistered already
try {
unregisterReceiver(broadcastReceiver);
} catch (IllegalArgumentException ignore) {}
And if you wrap the change in a method called safeUnregisterAndRemoveBroadcastReceiver
I would like to use that method for the other unregister as well (in the BroadcastReceiver).
Might it be that the revert did nothing about the memory leak, then? I suggest I merge your change when it is ready; I revert the revert; and then I can make an alpha release which you could test?
I added the method safeUnregisterAndRemoveBroadcastReceiver
and it works for me but I'm unable to test the receivedSms
callback.
The weak reference in Custom tabs login button is still needed. That was a different leak trace.
Will try to get this released before the weekend.
Thanks!
There is also an updated instant verification release (if you didn't already test the other one): https://github.com/telenordigital/connect-android-sdk/releases/tag/v1.11.2-beta
Awesome!
@simonnorberg: Did you get a chance to test the beta, by any chance? If you can log in once without any hiccups then it's probably fine.
If you don't have the time, then that is something I can relate to 😏.
@jorunfa I've tried 1.11.3-beta now and I can login without any problems.
Thanks for checking out!
We get an activity leak when we login with ChromeCustomTab in SDK 1.9.5. Possibly related to #145
It looks like smsBroadcastReceiver is only unregistered if an SMS is received? https://github.com/telenordigital/connect-android-sdk/blob/master/connect/src/com/telenor/connect/ConnectSdk.java#L152-L165
I'm not sure it is the best solution but unregistering/clearing smsBroadcastReceiver after successful login seems to fix the leak.