revanced-manager icon indicating copy to clipboard operation
revanced-manager copied to clipboard

fix: Specify build tools version for :api

Open validcube opened this issue 5 months ago • 22 comments

Use build tool 35.0.1 or above to stop build tool from generating AIDL file with unicode escape when the first character of the directory contain a "u"

See: https://issuetracker.google.com/issues/354735915

fixes https://github.com/ReVanced/revanced-manager/issues/2672

validcube avatar Jul 22 '25 13:07 validcube

This PR should be merged immediately when approved.

validcube avatar Jul 22 '25 13:07 validcube

What is the default one

oSumAtrIX avatar Jul 22 '25 13:07 oSumAtrIX

What is the default one

The default was build tool 35.0.0

(The default value is grabbed from the AGP 8.9.1, however as of right now the value is still the same with the latest version)

validcube avatar Jul 22 '25 13:07 validcube

I don't think we should hardcode. AGP should update to it

oSumAtrIX avatar Jul 22 '25 14:07 oSumAtrIX

I just realized something. Is there a reason why this is not done for app as well?

That's because :app already have specified build tools

validcube avatar Jul 22 '25 14:07 validcube

I don't think we should hardcode. AGP should update to it

AGP default (likely well tested in this case) hold the same weight as AGP minimum, so it should be fine to bump it.

https://developer.android.com/build/releases/gradle-plugin#compatibility

validcube avatar Jul 22 '25 14:07 validcube

I just realized something. Is there a reason why this is not done for app as well?

That's because :app already have specified build tools

Didn't realize that. I probably would have checked if I had access to a computer.

Axelen123 avatar Jul 22 '25 19:07 Axelen123

Approved unless the issue can be solved by bumping AGP.

Latest AGP still has 35.0.0 as default: image

brosssh avatar Jul 23 '25 08:07 brosssh

This PR should not be merged. Instead you should wait for AGP to update to the fixed build tools version, because this PR adds unnecessary maintenance burden (updating build tools manually) and doesn't even use the version catalog. This applies to the :app module

I've checked this, the AGP source does not set or dictate the specific dependency version needs to be used. If developers didn't specify which version to use, then AGP will get its default value, which by no means is the recommended version because there is none.

However if they do the AGP will let us know by crashing the right away or put it in documentation: see: https://developer.android.com/build/releases/gradle-plugin#updating-gradle

validcube avatar Jul 23 '25 10:07 validcube

Why does agp not default to the latest version

oSumAtrIX avatar Jul 23 '25 10:07 oSumAtrIX

Why does agp not default to the latest version

Library or dependency don't need to automatically update its default dependency or grab whatever latest from the server. That just wouldn't make sense in general.

validcube avatar Jul 24 '25 02:07 validcube

But Everytime agp is updated I'd suppose they update build tools too?

oSumAtrIX avatar Jul 24 '25 04:07 oSumAtrIX

They don't, 35.0.0 has been the default value since AGP 8.8.0. The latest AGP is 8.11, still version 35.0.0 is the default.

brosssh avatar Jul 24 '25 15:07 brosssh

That is odd. Why wouldn't they bump?

oSumAtrIX avatar Jul 24 '25 19:07 oSumAtrIX

That is odd. Why wouldn't they bump?

That's the minimum version (which happens to also be the default/fallback version), AGP support build tools 35.0.0 and above, the minimum is updated on an ad-hoc basis.

Version on build tools doesn't really matter much, because building a newer version of Android like Android 16 (36) works fine on older build tools like 35.0.0

validcube avatar Jul 25 '25 13:07 validcube

The app module already sets the build tools version and updating them isn't very important, so I don't think this PR adds a significant extra maintenance burden.

Axelen123 avatar Jul 25 '25 17:07 Axelen123

What I am saying applies to the app module as well. However as insignificant as it may look, it's an additional tech debt that you need to avoid if possible, and not just when it "looks significant". Setting the build tools version would require everyone to have that specific version too. Is that the case when unset?

oSumAtrIX avatar Jul 25 '25 17:07 oSumAtrIX

What I am saying applies to the app module as well. However as insignificant as it may look, it's an additional tech debt that you need to avoid if possible, and not just when it "looks significant". Setting the build tools version would require everyone to have that specific version too. Is that the case when unset?

I don't see why would bumping build tools would be considered as technical debt to the project? This PR bump the default of 35.0.0 to 35.0.1, this isn't done randomly but to fix an issue, so we actually reduce a tech debt by not having to wait for AGP to bump the minimum/default version to 35.0.1 or make workaround for user whose the first character of the directory is a "u".

But maybe when AGP finally does update the default/minimum version to 36.0.0[^1], we can remove it from the build config.

[^1]: (36.0.0 is not a mistake, they always update the major component, not patch unless critical)

validcube avatar Jul 30 '25 14:07 validcube

I don't see why would bumping build tools would be considered as technical debt to the project?

Because now you have to bump it from time to time manually.

so we actually reduce a tech debt by not having to wait for AGP to bump the minimum/default version to 35.0.1

Not doing something and waiting for something to happen is not a debt.

or make workaround for user whose the first character of the directory is a "u".

I personally would apply the ostrich algorithm and let time heal the wounds instead of casting an indefinite technical debt upon us. Is there a bump cycle? If it is not too long, then that's definitely the better course of action.

oSumAtrIX avatar Jul 30 '25 14:07 oSumAtrIX

I personally would apply the ostrich algorithm and let time heal the wounds instead of casting an indefinite technical debt upon us.

Using ostrich to ignore critical problem should not be the reason why this PR can't be merged when the fix is just one line and does not violate any android development rule.

Is there a bump cycle? If it is not too long, then that's definitely the better course of action.

There is no specific bump cycle for default/minimum version of build tools. If we were to have educated guesses from last time the minimum was bump, it would take around 14 months for AGP to bump it (AGP 8.2.0 Nov 2023 -> 8.8.0 Jan 2025) (additionally I have checked the latest alphas and they're still on 35.0.0)

Not doing something and waiting for something to happen is not a debt.

It is a debt because we didn't fix the issue that arises with using the default configuration.

Because now you have to bump it from time to time manually.

I don't see why this would be a problem as this is equivalent to updating a dependency.

validcube avatar Aug 09 '25 04:08 validcube

Using ostrich to ignore critical problem should not be the reason why this PR can't be merged when the fix is just one line and does not violate any android development rule.

In my opinion its a very niche problem and not critical that doesn't justify increasing tech debt.

It is a debt because we didn't fix the issue that arises with using the default configuration.

Its not our problem to fix. AGP updates automatically which would fix the issue without any intervention. If you hardcode now, you cast tech debt upon yourself for a one time niche problem (which isn't even our problem)

I don't see why this would be a problem as this is equivalent to updating a dependency.

Because its yet another hardcoded value in a random location you'll forget in two weeks.

oSumAtrIX avatar Aug 10 '25 17:08 oSumAtrIX

In that case the PR should be updated to adding support to AGP 9.0.0 as they bumped the minimum version of build tools allowed to 36.0.0

https://developer.android.com/build/releases/agp-preview (as of writing AGP version is 9.0.0-alpha06)

validcube avatar Sep 23 '25 10:09 validcube

This is already in the codebase image

Ushie avatar Dec 17 '25 20:12 Ushie

This is already in the codebase image

There's two module (app, api), one of them is using 35.0.0 because it wasn't specified in the config. Beside the discussed approach were to remove settings build tool config although for future AGP bump which as of writing is still on AGP 9.0.0-beta06

validcube avatar Dec 17 '25 21:12 validcube

I recommend updating to the kotlinAndroid library revanced patcher also will use, which is specifically crafted to configure the android plugin properly. The kotlinAndroid template shows how and you can take reference on patcher

oSumAtrIX avatar Dec 18 '25 00:12 oSumAtrIX