IssueTracker

Thanks for your detailed post.

However, benchmark build type is under configured: at least isProfileable is not set to true for existing build type, probably there's more.

We should set isProfileable = true by default when overriding an existing benchmark build type.

This issue is not about some specific configuration flag, but the general approach of dealing with external configuration. As a developer adopting baseline profiles, it seems extremely risky to me using a custom configuration due to how it's applied under the hood and the fact it may break default configuration.

I agree that is not great but this is a little tricky to do. For custom baseline profile build types we override all the properties. For benchmark I left it open to configure but it's mostly about these 2 properties:

isMinifyEnabled
isShrinkResources

I don't have a way to see if the user is setting them before overriding, so for this reason, I'd prefer not to. I agree with you that some other properties could be set by default to make this easier, i.e.:

isJniDebuggable = false
isDebuggable = false
isProfileable = true

The reason why I mentioned the release signing config in the beginning is because I want to use debug signing config.

In the specific of your issue, i.e. using a debug certificate can you override the benchmark and baseline profile setting? You should be able to do something like:

android {
    buildTypes {
        release { ... }
        debug { ... }
        benchmarkRelease {
            ...
            signingConfig signingConfigs.debug
        }
        nonMinifiedRelease {
            ...
            signingConfig signingConfigs.debug
        }
    }
}

Project: platform/frameworks/support
Branch: androidx-main
Author: Marcello Albano <maralb@google.com>
Link:      https://android-review.googlesource.com/3303459

Added override for debuggable and profileable for benchmark builds in bpgp

Added override for debuggable and profileable for benchmark builds in bpgp

Test: ./gradlew :benchmark:benchmark-baseline-profile-gradle-plugin:test
Bug: 369213505
Relnote: "isProfileable is always overridden in benchmark builds,
  and isDebuggable is also now always overridden in both benchmark and
  nonMinified (baseline profile capture) builds."
Change-Id: I487fa71083921682173f04fcbb477be5baf165f8

I've landed a change that will set the following properties also when the benchmark build type already exists:

isJniDebuggable = false
isDebuggable = false
isProfileable = true

As well as the following for agp 8.0:

isDebuggable = false

I'm going ahead and closing this - if you've further questions please answer here and will reopen. Thanks.

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.benchmark:benchmark-baseline-profile-gradle-plugin:1.4.0-alpha04

Since release signing config is used by default instead of debug is not mentioned in release notes - maybe this is a bug?

Cause the last time I found it mentioned in the release notes was in version 1.1

signingConfig.debug is used as the default signing config (b/153583269)

So, if the switch to the release one indeed happened - maybe it's an issue?

The new build types should inherit the certificates from the release build type, unless none is specified in which case debug is used: code link

This should be updated in the documentation, thanks for mentioning it. Will take care of updating it.

Hi there,

I'm having a very similar issue, if not the same. In the application I'm currently developing, I had a util class which allowed me to verify the Android version of the device. Here's an example:

fun isAtLeastQ(): Boolean {
        return Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q
    }

I had no issue when this class was in my application. But I decided to export this class into my personal lib, allowing me to use this class in multiple applications without having to copy and paste it. The class was absolutely unchanged, except that I moved it from my application to my lib.

After upgrading my lib in that app and replacing calls of isAtLeastQ() from my app to isAtLeastQ() from my lib, I noticed that Lint thought I didn't add verification of the API anymore.

In my screenshots, you can see the difference between both isAtLeastQ() (AndroidVersionBugApp.jpg) of my app, and isAtLeastQ() of my lib.

Additionally, I decided to try the BuildCompat class in which, even if isAtLeastQ() is deprecated, it is still available. I first thought I would still have the issue, but not at all. As you can see in the last screenshot (AndroidVersionBugBuildCompat.jpg), Lint isn't detecting any issue.

I use AGP 3.5.3 for both my application and my lib.

I use Jitpack to import my lib from Github to my project, so Jitpack is added under repositories, and my lib is added like this:

 implementation 'com.github.myusername:repo:version'

Thanks. I sent an email last Tuesday containing all the details.

Hi there, Dylan sent me steps to reproduce, and with that I was able to check in a fix (for 4.1 and 4.0) yesterday.

The root problem in his scenario is that there are cases where resolving a method call fails -- and that was happening in that particular scenario. That meant lint didn't get a chance to look at the method at all, to see if it's a version check. My fix was to more gracefully handle that, such that it now will still look at the method name and call the method name check even if it cannot find the associated method. So if the method is for example called "isAtLeastQ", it will from that conclude that the API level is at least 29 if that method returns true.

This all sounds different from your problem Brandon. The most likely explanation is the same: that somehow resolving the method calls is failing. The most common reason for that is a classpath setup. It's hard to say more without knowing how the build sets up your source build...

Started work on this in the form of a new annotation you can annotate custom API method checks (and fields and properties with) to teach lint that a given method represents an API constraint: https://android-review.googlesource.com/c/platform/frameworks/support/+/1300261/

(not yet ready to use; that annotation hasn't been released and lint doesn't know about it yet, but if you have thoughts on how it would work and how you would annotate your own API version utilities with it, speak up. See the javadoc for examples.)

I forgot to close this bug but this was fixed quite a while back -- Studio 4.2 and probably Studio 4.1 at least understand the new annotation -- but in 7.0 it will (a) automatically handle local binary dependencies (e.g. in your own libraries that lint runs on, it will recognize these API checks and make a note for itself which it uses downstream, and (b) can suggest actually annotating these methods such that other uses of the library can automatically see the inference as well.