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

Move Notifications to get triggered from NotificationEventListener #2395

Closed
wants to merge 19 commits into from

Conversation

sahil2441
Copy link
Contributor

@sahil2441 sahil2441 commented Jun 29, 2022

Fixes: #2394

Change
This PR moves the notifications triggering to the NotificationEventListener.

Test Plan

  • ./gradlew build --stacktrace
  • Install leakcanary sample with: ./gradlew leakcanary-android-sample:installDebug and ensure Notifications work as intended:

@CLAassistant
Copy link

CLAassistant commented Jun 29, 2022

CLA assistant check
All committers have signed the CLA.

@sahil2441 sahil2441 force-pushed the sahil2441/Issue-2394 branch from 6388c9c to 8efb01b Compare June 29, 2022 01:26
@ashish-kshirsagar
Copy link

Hi,
I have noticed that on Android 13 with changing notification permission to run-time permission, leak canary triggers a dialog to show upon app launch. This affects the automation tests and other user flows.

Can above solution allow to suppress or delay creation of notification channel after enabling permission ?

Thanks,
Ashish

@pyricau
Copy link
Member

pyricau commented Jul 8, 2022

I have noticed that on Android 13 with changing notification permission to run-time permission, leak canary triggers a dialog to show upon app launch.

@ashish-kshirsagar Can you file a new issue that references this PR, with a screenshot and ideally a repro scenario?

@sahil2441 sahil2441 changed the title [WIP] Move Notifications to get triggered from NotificationEventListener Move Notifications to get triggered from NotificationEventListener Jul 10, 2022
@sahil2441 sahil2441 marked this pull request as ready for review July 10, 2022 21:02
@sahil2441 sahil2441 requested a review from pyricau July 10, 2022 21:02
@sahil2441
Copy link
Contributor Author

Strange that the unit tests which are failing in CI jobs are passing locally with:
./gradlew :shark-android:test

@pyricau Looks like it's due to difference in heap size expected; Does the heap size here vary with the machine it's generated on?

@sahil2441
Copy link
Contributor Author

@pyricau PTAL

@sahil2441
Copy link
Contributor Author

@pyricau ptal

@@ -154,7 +141,6 @@ internal class HeapDumpTrigger(
return
}

dismissRetainedCountNotification()
Copy link
Member

Choose a reason for hiding this comment

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

Looks like this has been replaced by new behavior in the event listener class, as I'm seeing no direct call to dismissRetainedCountNotification()

@@ -193,10 +176,9 @@ internal class HeapDumpTrigger(
lastDisplayedRetainedObjectCount = 0
lastHeapDumpUptimeMillis = SystemClock.uptimeMillis()
objectWatcher.clearObjectsWatchedBefore(heapDumpUptimeMillis)
currentEventUniqueId = UUID.randomUUID().toString()
Copy link
Member

Choose a reason for hiding this comment

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

currentEventUniqueId was previously changing on every actual dump. Looks like that's not the case anymore? So all dump heap events get the same id? That doesn't seem right?

assertThat(retained after FINDING_DOMINATORS).isEqualTo(7.02 MB +-5 % margin)
assertThat(retained after INSPECTING_OBJECTS).isEqualTo(7.02 MB +-5 % margin)
assertThat(retained after COMPUTING_NATIVE_RETAINED_SIZE).isEqualTo(7.02 MB +-5 % margin)
assertThat(retained after COMPUTING_RETAINED_SIZE).isEqualTo(5.77 MB +-5 % margin)
Copy link
Member

Choose a reason for hiding this comment

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

Definitely an unexpected change, yes it changes per env. I'd try rebasing & seeing if CI passes with and without this.

)
}

is Event.ShowRetainedCountNotification -> {
Copy link
Member

Choose a reason for hiding this comment

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

Ideally the names of the events wouldn't have "Notification" in them, and instead describe "what just happened". Then the notification listener can turn those events into the proper notifications.

@pyricau
Copy link
Member

pyricau commented Nov 10, 2022

Thanks so much for your work Sahil! I'm sorry it took so long for me to review. After thinking through this some more, I'm realizing our notification code is tightly coupled to the rest of the logic and hard to move around without introducing bugs , which is why I hadn't moved those notifications in the first place. I'm not super comfortable with the risk involved here, so I went back to the original ticket and thought about your concrete need, and then landed a PR with less changes, though that leaves the current code in its not so great shape: #2440

I hope you won't mind me closing this PR.

@pyricau pyricau closed this Nov 10, 2022
@sahil2441
Copy link
Contributor Author

@pyricau ty! no worries.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Provide a way to disable all notifications
5 participants