Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(#376): fix issue of the app crashing in some phones #377

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

sugat009
Copy link
Member

@sugat009 sugat009 commented Oct 4, 2024

fixes: #376

The issue seems to be a case when during some events the OpenSettingsDialogFragment is not able to find its calling activity which in this case is EmbeddedBrowserActivity and since it can't find EmbeddedBrowserActivity it's also not able to find the view wbvMain which in turn is unable to set the setOnTouchListener onto the view because the view is null. So, I've added a fallback and retry mechanism to give time for the EmbeddedBrowserActivity to load and be "findable" and also retain the instance of OpenSettingsDialogFragment because it's just a background listener that listens for taps and swipes.

@sugat009 sugat009 added the Type: Bug Fix something that isn't working as intended label Oct 4, 2024
@sugat009 sugat009 self-assigned this Oct 4, 2024
@sugat009 sugat009 linked an issue Oct 4, 2024 that may be closed by this pull request
Copy link
Contributor

@latin-panda latin-panda left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a couple of questions

How did you reproduce this error in phones? Following Binod's steps?

@@ -59,6 +61,8 @@ public void setup() {
doNothing().when(openSettingsDialogFragment).startActivity(argsStartActivity.capture());

openSettingsDialogFragment.onCreate(null);
openSettingsDialogFragment.onActivityCreated(null);
shadowOf(Looper.getMainLooper()).idle();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this test already covering the error when the fragment is unavailable, and do the retry?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not at the moment. I saw that the tests in this file were related to the behavior of the Fragment and decided not to add the test as it's an internal functionality. I could add it if it's needed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to add a unit test to catch this bug in particular? It can be a good addition to prevent regressions and also as an example for similar future implementations

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The setRetainInstance is deprecated in androidx, this unit test can help the developer to consider that case when migrating to a more recent androidx lib.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, let me add a test for that.


import java.time.Clock;
import java.time.Instant;
import java.time.ZoneOffset;
import java.util.stream.IntStream;

@RunWith(RobolectricTestRunner.class)
@RunWith(Enclosed.class)
@SuppressWarnings("PMD.TestClassWithoutTestCases")
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@latin-panda I've created a nested class to enclose the testing of the setupViewWithRetry method because the mocks of the previous test cases were not reusable for it. Also, I've added this warning suppress statement because PMD was raising an error as to the outer class not having any test cases.

Copy link

@tatilepizs tatilepizs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the fix @sugat009

I was able to replicate the error using a Samsung Galaxy A01 phone with Android 10 on master branch.

androidCrash_master.mov

And it was fixed on 376-google-reporting-app-crashes-on-some-phones branch

fix.mov

@@ -33,8 +37,44 @@ public boolean onTouch(View view, MotionEvent event) {
@Override
public void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setRetainInstance(true);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, I am probably missing something here, but in my testing, adding this line here in the onCreate was all that I needed to avoid the error in question.

In my debugging it seemed like without this line, the OpenSettingsDialogFragment.onCreate method was getting called a bunch of times when entering/exiting split-screen mode before the EmbeddedBrowserActivity.onCreate method is even called. When this happened, the wbvMain view was still null (presumably because the activity was not created yet). Eventually, the EmbeddedBrowserActivity.onCreate method is called for the new activity and that triggers the OpenSettingsDialogFragment.onCreate method to be called again (and this time the wbvMain view exists.

However, if I set setRetainInstance(true); here in OpenSettingsDialogFragment.onCreate and leave everything else as it is in master, it prevents all the extra initial calls to EmbeddedBrowserActivity.onCreate that were happening before EmbeddedBrowserActivity.onCreate and so avoids the error. When the EmbeddedBrowserActivity.onCreate function is called, that triggers a call to OpenSettingsDialogFragment.onCreate which then can access the wbvMain view at that point in the lifecycle.

I am not 100% sure about exactly what is happening here. The EmbeddedBrowserActivity.onCreate is not getting called multiple times. My theory is that there is some weird connection between the activity lifecycle and the fragment lifecycle that is causing the OpenSettingsDialogFragment.onCreate function to get called at other points during the activity lifecycle as the original EmbeddedBrowserActivity is destroyed. Setting setRetainInstance seems to decouple the fragment from the activity lifecycle so that this does not happen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Bug Fix something that isn't working as intended
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Google reporting app crashes on some phones
4 participants