Unstable benchmark and Baseline Profiles build types customization [369213505]

Fixed

Bug

Status Update

No update yet.

Description

an...@sigma.software

created issue #1

Sep 24, 2024 10:46AM

In recent 1.3.0 update of androidx.benchmark library there's a breaking change. Now release signing config is used by default instead of debug. It's not mentioned in a corresponding release notes whatsoever.

As per official documentation, there's a way to customize benchmark and baseline profiles build types.

Having reviewed the source code of baseline profiles Gradle plugin, I can see that creating a custom configuration (build type) results in inconsistent final variant properties. I'll explain directly in code.

There's a class BaselineProfileAppTargetAgpPlugin responsible for creating corresponding build types (nonMinifiedRelease, benchmarkRelease). It's actually done in createBuildTypesWithAgp81AndAbove() method. There's a helper method createExtendedBuildTypes() that checks whether a build type exists or not, and executes different configuration blocks based on build type existence (newConfigureBlock, overrideConfigureBlock).

Now, baseline profiles build type configuration is identical both for new and existing build type. However, benchmark build type is under configured: at least isProfileable is not set to true for existing build type, probably there's more.

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.

The reason why I mentioned the release signing config in the beginning is because I want to use debug signing config. I'm unable to find any way to configure already created by your plugin build type. So the ideal solution I see is to allow configuring existing (already created by plugin) build types (nonMinifiedRelease, benchmarkRelease) instead of forcing developers actually create these. This way there won't be any discrepancies between the default and customized build types.

Summing up, there are two action points:

Determine if it's possible to eliminate discrepancies between configuring new and existing build types
Figure out how to change signing config back to debug without affecting default build type configuration (ref. to 1)

Comments

cc...@google.com <cc...@google.com> Sep 24, 2024 10:43PM

Reassigned to ma...@google.com.

ma...@google.com <ma...@google.com> #2Oct 8, 2024 05:11PM

Any suggestions on where such an interface might live? I don't think it makes sense for the interface to be in the drawerlayout artifact if you're specifically going to use the interface to *not* use DrawerLayout.

ap...@google.com <ap...@google.com> #3Oct 11, 2024 06:58PM

androidx.customview would be a good candidate. This is used by all of the widget libraries.

ma...@google.com <ma...@google.com> #4Oct 11, 2024 07:09PM

Marked as fixed.

Project: platform/frameworks/support
Branch: androidx-master-dev

commit 3ed3fb003fa6c1244f923202859a616225b5b2fa
Author: Ian Lake <ilake@google.com>
Date: Fri Feb 14 11:17:46 2020

Create an interface for layouts that can be opened

Create a common interface that represents layouts
that have two states: open and closed. This allows
higher level libraries to rely on the interface,
rather than concrete implementations such as
DrawerLayout, making them more resilient to
changes in the current recommended implementation.

Fixes: 129979320
Test: ./gradlew checkApi
Change-Id: I0f2a1414977825aa053c6555261f2b7d4417bd19

M customview/customview/api/1.1.0-alpha02.txt
M customview/customview/api/current.txt
M customview/customview/api/public_plus_experimental_1.1.0-alpha02.txt
M customview/customview/api/public_plus_experimental_current.txt
M customview/customview/api/restricted_1.1.0-alpha02.txt
M customview/customview/api/restricted_current.txt
A customview/customview/src/main/java/androidx/customview/widget/Openable.java
M drawerlayout/drawerlayout/api/1.1.0-alpha03.txt
M drawerlayout/drawerlayout/api/current.txt
M drawerlayout/drawerlayout/api/public_plus_experimental_1.1.0-alpha03.txt
M drawerlayout/drawerlayout/api/public_plus_experimental_current.txt
M drawerlayout/drawerlayout/api/restricted_1.1.0-alpha03.txt
M drawerlayout/drawerlayout/api/restricted_current.txt
M drawerlayout/drawerlayout/build.gradle
M drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java
M jetifier/jetifier/migration.config
M slidingpanelayout/slidingpanelayout/api/1.1.0-alpha01.txt
M slidingpanelayout/slidingpanelayout/api/current.txt
M slidingpanelayout/slidingpanelayout/api/public_plus_experimental_1.1.0-alpha01.txt
M slidingpanelayout/slidingpanelayout/api/public_plus_experimental_current.txt
M slidingpanelayout/slidingpanelayout/api/restricted_1.1.0-alpha01.txt
M slidingpanelayout/slidingpanelayout/api/restricted_current.txt
M slidingpanelayout/slidingpanelayout/src/main/java/androidx/slidingpanelayout/widget/SlidingPaneLayout.java

https://android-review.googlesource.com/940787

pr...@google.com <pr...@google.com> #5Oct 30, 2024 05:37PM

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

li...@gmail.com <li...@gmail.com> #6Nov 27, 2024 01:07PM

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?

Message last modified on Nov 27, 2024 01:10PM

ma...@google.com <ma...@google.com> #7Nov 27, 2024 08:29PM

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.