IssueTracker

Digging further, this isn't a problem with Gradle, but rather the AAPT daemon, probably due to a unpushed change occurring around this part of the code: https://android.googlesource.com/platform/frameworks/base/+/master/tools/aapt2/cmd/Link.cpp#764

Can this ticket please be reassigned to the appropriate component?

To reproduce:
$ANDROID_HOME/build-tools/27.0.3/aapt2 link --manifest $BUTTERKNIFE_REPO_CLONE_ROOT/butterknife/build/intermediates/manifests/aapt/release/AndroidManifest.xml -o .

The issue doesn't occur when I explicitly define build-tools v27.0.1 in my build.gradle (which requires a downgrade to AGP 3.1.0-alpha09), so it looks like the issue was introduced in build-tools v27.0.2 (a file size check also appears to confirm this, although I realize that's not a foolproof indicator).

$ANDROID_HOME/build-tools/27.0.1/aapt2 version
Android Asset Packaging Tool (aapt) 2:19
$ANDROID_HOME/build-tools/27.0.2/aapt2 version
Android Asset Packaging Tool (aapt) 2:19
$ANDROID_HOME/build-tools/27.0.3/aapt2 version
Android Asset Packaging Tool (aapt) 2:19

ls -l $ANDROID_HOME/build-tools/27.0.1/aapt2
-rwxr-xr-x  1 jrod  2853  2739732 Dec 22 17:59 $ANDROID_HOME/build-tools/27.0.1/aapt2
ls -l $ANDROID_HOME/build-tools/27.0.2/aapt2
-rwxr-xr-x  1 jrod  2853  2740588 Dec 16 12:22 $ANDROID_HOME/build-tools/27.0.2/aapt2
ls -l $ANDROID_HOME/build-tools/27.0.3/aapt2
-rwxr-xr-x  1 jrod  2853  2740588 Dec 22 16:49 $ANDROID_HOME/build-tools/27.0.3/aapt2

I'm unfamiliar with how AAPT is versioned, but examining its release notes history, perhaps some changes were made recently without updating the version/release notes?

Having a package name like 'butterknife' fails to install. The check has moved to AAPT2 to help developers catch this earlier.

adb: failed to install /mnt/android/master/out/target/product/generic/data/app/Test/Test.apk: Failure [INSTALL_PARSE_FAILED_BAD_PACKAGE_NAME: Invalid manifest package: must have at least one '.' separator]

This is a library, not an app. That check should be done in Gradle against the applicationId for users of com.android.application plugins and not in the tooling that has to process resources for libraries and applications.

Or a flag to aapt2 that this is for a library such that the check is not run.

Getting this with a second library now that uses a single element package name for its manifest and code.

So AAPT2 doesn't allow package names containing a single word, right? I have a multi-module Android project and one of these modules has a package name 'base'. Now after enabling AAPT2 I'm getting the following error:

error: attribute 'package' in <manifest> tag is not a valid Android package name: 'base'.

Is it a bug or intended behavior? Do I have to rename the package now?

This is "working as coded". However, there can be an argument to be made to allow this for libraries since they're never installed on device. It's unclear what this means to namespacing because we expect the package name to be a valid java name [ie. at least one '.'].

+Izabela
Could we move this check to Gradle when building applications and remove this logic from AAPT2? We could then change the error into a warning for people using AAPT2 directly.

> the package name to be a valid java name [ie. at least one '.']
But this is valid java package name and it's not so rare to have one level package (and some even advocate for this practice to have shorter packages)

if you want to use short package name, you need to start with a dot like '.base' and it will be added to your main package name by the manifest merger.
is this what you are doing ?

@10 Yeah, doing a package name validity check on our side makes sense.

Any updates on this?

Check added in 3.5

We're still working on allowing package names without dots in library modules. I'll update this bug once that's in.

@11 For application modules we now detect early if the package is incorrect. The check can now be removed from AAPT2.

It sure is.  We're having to rewrite the package & namespace now we've upgraded to Bazel 4.