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

A couple of questions:

1. Have you saw crash in real device or only in simulators?
2. Do you use dynamic feature for language ID?

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

Tested on Android 12 Emulator with custom executor, but cannot repro this issue.

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

Marked as fixed.

Second crash in the description is from a real device. Experienced it myself on two different Xiaomi phones, plus lots of crashes from users in the Google Play console.
Dynamic features are not used in the application.

As a wild guess, I have downgraded build tools from 31.0.0 to 30.0.3, compileSdk from 31 to 30, and moved all work with Language ID to the service in a separate process (just to be sure that crash can kill secondary process instead of main). This combination is in beta for 2 days by now and I don't see any SIGSEGV crashes.

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

Hmm, I feel the crash might be something related to separate/secondary process.

I also changed compileSdk and targetSDK to 31 but still cannot repro this issue.

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

On the contrary, there was no separate process before, when crashes started.

In the new build (with the aforementioned changes) I can see SIGSEGV crash, but only one instead of dozens and it has a bit different backtrace:

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)
liblanguage_id_jni.so (offset 0x11e000)

backtrace:
  #00  pc 000000000003c7c0  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 000000000003b960  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 000000000003bb48  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 000000000003bafc  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000036c98  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000032714  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000031cac  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000057438  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/oat/arm64/base.odex (offset 0x57000)

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

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

FYI, ML Kit launched a new language ID SDK in the latest release, which uses a new language ID model. https://developers.google.com/ml-kit/release-notes#august_11_2021

Could you try the new SDK version(17.0.0) to check if you can still repro this native crash? Thanks!