AGP should fail to build if AAPT attempts to parse too large of a string [300700353]

Assigned

Feature Request

Reviewed (L1)

Status Update

No update yet.

Description

nj...@google.com

created issue #1

Sep 15, 2023 10:55PM

TLDR: AGP should fail to build if AAPT fails to parse an xml string resource that is too large.

If an Android application includes a string xml resource that exceeds 32k characters, AAPT will fail to encode this string and instead replace it with "STRING_TOO_LARGE". This unfortunately has impacted a few 3p developers that are including xml based vector assets that include path strings that are very large (> 32k characters). AAPT ends up replacing this path information with the actual string "STRING_TOO_LARGE" which ends up failing parsing of the vector asset at runtime.

There was an initial attempt to detect this error at runtime and throw a corresponding error to the developer, however, instead we should front load this error at build time. It appears that when working on the following CL with test to verify this error is being detected, androidx infra is properly failing the build on this warning, however, this does not appear to be the default behavior for AGP.

See: https://android-review.git.corp.google.com/c/platform/frameworks/support/+/2753066 Androidx

And corresponding error here:

build_log_simplifier.py: Error: Found 3 new lines of warning output!

The new output:
> Task :navigation:navigation-compose:navigation-compose-samples:generateDebugAndroidTestResources UP-TO-DATE
error: string too large to encode using UTF-8 written instead as 'STRING_TOO_LARGE'.



To reproduce this failure:
Try $ ./gradlew -Pandroidx.validateNoUnrecognizedMessages --rerun-tasks :navigation:navigation-compose:navigation-compose-samples:generateDebugAndroidTestResources UP-TO-DATE

Instructions:
If you can fix these messages, do so.
If you cannot fix these messages, you may suppress them.
To automatically suppress new output from build server builds, run development/build_log_simplifier/update.sh
See also https://android.googlesource.com/platform/frameworks/support/+/androidx-main/development/build_log_simplifier/VALIDATION_FAILURE.md

Files:
Full Log                   : /buildbot/dist_dirs/aosp-androidx-main-linux-androidx_max_dep_versions/P62639724/logs/gradle.log
Baseline                   : /mnt/disks/build-disk/src/android/androidx-main/frameworks/support/development/build_log_simplifier/messages.ignore
Autogenerated new baseline : /buildbot/dist_dirs/aosp-androidx-main-linux-androidx_max_dep_versions/P62639724/logs/gradle.log.ignore
Gradle command failed:
./gradlew \
--ci \
assembleRelease \
assembleAndroidTest \
-Pandroidx.useMaxDepVersions \
-Dandroid.experimental.disableCompileSdkChecks=true

Comments

je...@google.com <je...@google.com> Sep 18, 2023 06:31PM

Reassigned to lu...@google.com.

cm...@google.com <cm...@google.com> #2Sep 19, 2023 11:56AM

https://issuetracker.google.com/123834692 "string too large to encode using UTF-8 written instead as 'STRING_TOO_LARGE'" during build

https://issuetracker.google.com/145308584 Error STRING_TOO_LARGE but no such string can be found in the resources

cm...@google.com <cm...@google.com> #3Sep 19, 2023 11:58AM

Thanks for your request. We will investigate this issue and see if we can implement the behavior you've requested.

lu...@google.com <lu...@google.com> Jan 18, 2024 03:35PM

Reassigned to sh...@google.com.

je...@googlemail.com <je...@googlemail.com> #4Jul 25, 2024 10:09AM

As an additional alternative, it should be possible to specify a label in the options for GmailApp.sendEmail().

A work-around is proposed in StackOverflow:

http://stackoverflow.com/a/18727687/1677912

cm...@google.com <cm...@google.com> #5Nov 7, 2024 04:48PM

Reassigned to zy...@google.com.

Are there any news on adding the ability to archive and add a label to specific emails (not threads)? From a corporate shared mailbox perspective auto threading emails by subject is a serious issue (eg. we recive two emails from the same person with same subject but with different description).

Since it's available in pure mailbox view is that such a big effort to make it available also in Google Script?

zy...@google.com <zy...@google.com> #6Feb 3, 2025 11:07PM

Reassigned to ma...@google.com.

Looking forward to having this implemented. As has been mentioned automatic threading based on subject is a big no-no for our enterprise. We get automated reports and other documents sent to us by customers and suppliers and they are lumped together in threads making it very difficult for me to let Apps Script process them automatically since labels (i.e. outlook folders) have to be applied to entire threads (even though the messages in these threads often need to be treated differently).