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

Provide a way to avoid installing the default InstallableWatchers in tests #2400

Open
hichamboushaba opened this issue Jul 14, 2022 · 2 comments

Comments

@hichamboushaba
Copy link

LeakCanary has a check to avoid checking for leaks in tests, but it's done later in the process when checking for retained objects, and LeakCanary still installs the default InstallableWatchers in test builds.

This has a side effect, as the ServiceWatcher swaps the instance of IActivityManager with a new proxy instance, it causes an issue with Fastlane's screengrab, as it relies on reflection to access the IActivityManager instance to handle Locale switching, this is the cause of this fastlane/fastlane#19521 (at least it's for us, as there may be other libraries that cause it too).
To solve this, currently, we are switching to the leakcanary-android-core artifact, and handling LeakCanary's initialization manually, but it would be awesome if LeakCanary did this automatically, maybe by adding the check to the MainProcessAppWatcherInstaller? 🤔

This is a continuation of the discussion started in #1552
@hichamboushaba hichamboushaba changed the title Provide a way to avoid installing the default InstallableWatchers in unit tests Provide a way to avoid installing the default InstallableWatchers in tests Jul 14, 2022
@pyricau
Copy link
Member

pyricau commented Nov 10, 2022

Thanks for the bug report. The thing that makes this tricky is that we default to disabling LeakCanary in test, but we also want people to leverage the instrumentation test artifact and actually do detect leaks in test (just differently), and in that case we do want the service watcher to be installed.

Note that the change could also be done on the fast lane side, by getting method from the proper real classes based on API levels instead of retrieving amnClass

@hichamboushaba
Copy link
Author

Thanks @pyricau, and sorry for the late reply.

I'll trust your judgment here, if you believe this behavior should be kept in the library, feel free to close the ticket, there is always the solution of using leakcanary-android-core and starting LeakCanary manually.

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

No branches or pull requests

2 participants