You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The automatic instrumentation tools in this project are opt-in, so users would have to manually add them on top of the core lib in order to use them in their projects. While the core lib must remain compatible with our minimum API version, it might not be the case for auto-instrumentation ones, since those could target code that became available in newer API versions, such as the http URLConnection methods added in API 24 that are mentioned here.
In this example, the host project's code is inspected to look for usages of URLConnection methods in order to replace them with wrappers, so if a host project with a min API lower than 24 (21 for example) gets this auto-instrumentation added, then the instrumentation would never have to replace methods that aren't available on API 21, even though it could if it found them. So in that sense, making the httpurlconnection auto-instrumentation unaware of API limitations shouldn't cause issues, although we should validate in tests that for projects with lower APIs there won't be any runtime exceptions due to no methods found when the wrapper class is loaded.
The text was updated successfully, but these errors were encountered:
The automatic instrumentation tools in this project are opt-in, so users would have to manually add them on top of the core lib in order to use them in their projects. While the core lib must remain compatible with our minimum API version, it might not be the case for auto-instrumentation ones, since those could target code that became available in newer API versions, such as the http URLConnection methods added in API 24 that are mentioned here.
In this example, the host project's code is inspected to look for usages of URLConnection methods in order to replace them with wrappers, so if a host project with a min API lower than 24 (21 for example) gets this auto-instrumentation added, then the instrumentation would never have to replace methods that aren't available on API 21, even though it could if it found them. So in that sense, making the httpurlconnection auto-instrumentation unaware of API limitations shouldn't cause issues, although we should validate in tests that for projects with lower APIs there won't be any runtime exceptions due to no methods found when the wrapper class is loaded.
The text was updated successfully, but these errors were encountered: