-
Notifications
You must be signed in to change notification settings - Fork 624
Always call foreground activity callbacks on the UI thread #4531
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
Conversation
This will make it easier to reason about what runs on what thread.
Generated by 🚫 Danger |
// construct FirebaseAppDistribution instance on startup so we can register for | ||
// activity lifecycle callbacks before the API is called | ||
.alwaysEager() | ||
.build(), | ||
Component.builder(FeedbackSender.class) | ||
.add(Dependency.required(FirebaseApp.class)) | ||
.add(Dependency.requiredProvider(FirebaseInstallationsApi.class)) | ||
.add(Dependency.required(backgroundExecutor)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I realized this wasn't used in FeedbackSender.
Coverage Report 1Affected Products
Test Logs |
Size Report 1Affected Products
Test Logs |
Startup Time Report 1Note: Layout is sometimes suboptimal due to limited formatting support on GitHub. Please check this report on GCS. Startup time comparison between the CI merge commit (e4911fa) and the base commit (8549013) are not available. No macrobenchmark data found for the base commit (8549013). Analysis for the CI merge commit (e4911fa) can be found at: |
* Always call foreground activity callbacks on the UI thread This will make it easier to reason about what runs on what thread. * Refactor getActivityWithIgnoredClass to consolidate synchronized blocks
* Always call foreground activity callbacks on the UI thread This will make it easier to reason about what runs on what thread. * Refactor getActivityWithIgnoredClass to consolidate synchronized blocks
* Always call foreground activity callbacks on the UI thread This will make it easier to reason about what runs on what thread. * Refactor getActivityWithIgnoredClass to consolidate synchronized blocks
This will make it easier to reason about what runs on what thread.