Fixed
Status Update
Comments
sp...@google.com <sp...@google.com>
je...@google.com <je...@google.com>
lu...@google.com <lu...@google.com> #2
To give more color to this, every android related library or framework that I use is initialized by passing it a Context. This allows me to have a ContentProvider where I can do all my initialization. The benefits of this are:
1. Abstraction - my app module doesn't need to know about anything other than my internal modules and doesn't interface directly with libraries
2. An Application is built for each process, which means that we now have a CameraXConfig.Provider for secondary processes like a crash reporting process, etc... ContentProvider is only created once across all processes (and can be set to create one per process for apps that need to configure the camera across multiple processes, which I'm positive are very rare)
TL;DR the recent trend has been to move away from Application as a source of configuration for a variety of benefits
1. Abstraction - my app module doesn't need to know about anything other than my internal modules and doesn't interface directly with libraries
2. An Application is built for each process, which means that we now have a CameraXConfig.Provider for secondary processes like a crash reporting process, etc... ContentProvider is only created once across all processes (and can be set to create one per process for apps that need to configure the camera across multiple processes, which I'm positive are very rare)
TL;DR the recent trend has been to move away from Application as a source of configuration for a variety of benefits
Description
DESCRIBE THE ISSUE IN DETAIL: Stop creating androidJacocoAnt configuration if coverage is not enabled. We are wasting resources to create it.
STEPS TO REPRODUCE:
Expected:
There is no jacoco listed in dependencies
Actual
There is: