cmake: match Soong global native defines

[FuPeiJiang]

Summary

Soong applies common native compiler flags globally. In build/soong/cc/config/global.go, those flags include:

-DANDROID
-DNDEBUG
-UDEBUG

The CMake port was only applying NDEBUG ad hoc to libandroidfw, which meant some targets and dependencies could be built with different assertion behavior. In particular, libaapt saw NDEBUG, but libutils did not, so a default host CMake aapt build could abort in VectorImpl::itemLocation() on a debug-only assertion that the Soong-style build would compile out.

Match Soong's global native defines at the top level instead, and remove the ad hoc NDEBUG from libandroidfw.

Testing

Locally tested the same change in an initialized checkout:

• default CMake host build of the full target set succeeded
• verified VectorImpl.cpp compile line includes -DANDROID, -DNDEBUG, and -UDEBUG
• verified ResourceTable.cpp compile line includes -DANDROID, -DNDEBUG, and -UDEBUG
• ran a minimal aapt package command against android-36/android.jar; it succeeded and produced an APK

The same minimal command aborted before this change with:

F Vector  : [...] itemLocation: index=0, capacity=0, count=0

[robertkirkman]

@Biswa96 this is very cool, do you see how this seems to match this code in Soong?

https://android.googlesource.com/platform/build/soong/+/master/cc/config/global.go/#107

does this fix the problem for you?

[Biswa96]

Thank you for the solution. Is it required to add the -DNDEBUG flag globally? -DCMAKE_BUILD_TYPE=Release option adds that compiler flag. Building with that cmake option fixes the issue. I think no changes are required for now.

[robertkirkman]

@FuPeiJiang by default, without intervention, the CMake integration of the termux-packages build scripts in GitHub Actions will set -DCMAKE_BUILD_TYPE=Release. However, the scripts/run-docker.sh ./build-package.sh -I -f -d aapt command (with manual -d for debug, which is not the default in Termux GitHub Actions CI) will not set that, so in the edge case of a developer debugging the package, the issue could reappear even if it's not the thing being debugged. Do you think it's fine to rely on the automatic -DCMAKE_BUILD_TYPE=Release of termux-packages build system to avoid the problem, or do you prefer to ensure -DNDEBUG is always unconditionally set?

[robertkirkman]

I think no changes are required for now.

so far, the events suggest that upstream Android developers probably develop aapt entirely with -DNDEBUG unconditionally set, resulting in the incompatibility of the source code logic with non--DNDEBUG build systems, but that is speculative. If that is the case, the question of whether globally adding -DNDEBUG in the build system is good or bad becomes murky and subjective.

[FuPeiJiang]

Given that -DCMAKE_BUILD_TYPE=Release fixes this and Termux package builds already use that by default, I am fine closing this.

My only reason for considering a build-system change was that someone did trip over the default/no-build-type CMake behavior, so making CMake mirror Soong's global -DNDEBUG would avoid that developer-debug edge case. But I personally have not hit this in the normal package build path, and I agree the question becomes subjective once Release builds are confirmed to work.

So I will close this PR for now. The practical takeaway is that release-style CMake builds should be used for these tools, and non-NDEBUG builds may expose upstream source paths that Android's normal build flags do not exercise.

[robertkirkman]

@Biswa96 after the resolution of this concern, if your tests are now working with -DCMAKE_BUILD_TYPE=Release, are you ready to proceed forward with any other steps you preferred to do in between now, and creating a tag in this repository?

[Biswa96]

Which tag style would be nice for this project? e.g. 16.0.0.4 or android-16.0.0_r4 or 16.0.0_r4. I prefer the first one because some distribution don't prefer underscore or letters in version.

[FuPeiJiang]

I also prefer 16.0.0.4.

I would use the plain converted AOSP version for the first tag for that AOSP base:

16.0.0.4      # first tag for android-16.0.0_r4

If a follow-up android-build-tools-only fix is needed while still staying on the same AOSP base, then add another numeric component:

16.0.0.4.1    # first follow-up fix after 16.0.0.4, still based on android-16.0.0_r4
16.0.0.4.2    # second follow-up fix after 16.0.0.4, still based on android-16.0.0_r4
16.0.0.5      # first tag for android-16.0.0_r5

That keeps tags distro-friendly, sortable, and avoids letters/underscores.

[robertkirkman]

I agree with FuPeiJiang's idea because it would make the tag line up with Termux's repology version for the current version without having to use separate variables

also the point about what to do if termux/android-build-tools repository needs to make further changes without upstream releasing a new version is good