A common pattern in Android development is use (and define) methods that require a specific Android API version at runtime, indicated with the @RequiresApi annotation. There are then warnings at development time if those methods are used in an application that has a lower allowed runtime level without the calls being gated on appropriate runtime checks (e.g., a Build.VERSION check, or being in a method that is itself annotated @RequiresApi with as high or higher an API).
Ideally we would want a solution that provides a similar level of linter/analyzer-based checking, otherwise a very common class of issues will move from being easily found at development time (authoring in Java) to only being found when testing that specific codepath on a sufficiently old device/emulator, which is dramatically worse as a developer (and if something goes wrong as a result, end user) experience.
A common pattern in Android development is use (and define) methods that require a specific Android API version at runtime, indicated with the
@RequiresApi
annotation. There are then warnings at development time if those methods are used in an application that has a lower allowed runtime level without the calls being gated on appropriate runtime checks (e.g., aBuild.VERSION
check, or being in a method that is itself annotated@RequiresApi
with as high or higher an API).Ideally we would want a solution that provides a similar level of linter/analyzer-based checking, otherwise a very common class of issues will move from being easily found at development time (authoring in Java) to only being found when testing that specific codepath on a sufficiently old device/emulator, which is dramatically worse as a developer (and if something goes wrong as a result, end user) experience.