Wrong and inconsistent file location for new transform API [174678813]

Fixed

Bug

Status Update

No update yet.

Description

to...@gmail.com

created issue #1

Dec 3, 2020 01:14AM

New transform API provide wrong and inconsistent input and output folder for transform.

For single file artifact like bundle
variant.artifacts.use(updateBundleArtifact)
.wiredWithFiles(
UpdateArtifactTask::initialArtifact,
UpdateArtifactTask::updatedArtifact
)
.toTransform(ArtifactType.BUNDLE)

it set this value
originalArtifact: app\build\outputs\bundle\debug\signDebugBundle\app-debug.aab
updatedArtifact: app\build\outputs\bundle\debug\debugUpdateArtifact\out

There are more weird things:
- why there is this "sign" prefix for the original file? It should be just "debugBundle"
- why output file is "out". and not app-debug.aab
- According to Xavier Ducrohet only the final artifact should be inside of outputs folder
- Then I don't see the reason for changing the name of the folder debugBundle to debugUpdateArtifact (if only final artifact should be there), it will really help with old plugins that will not use new variant API and will depend on the hardcoded path.
- I would really appreciate if there will be also the possibility to change the name of the output artifact during this transform, not the only file content.

And when I use this

variant.artifacts.use(updateApkArtifact)
.wiredWithDirectories(
UpdateDirArtifactTask::inputDir,
UpdateDirArtifactTask::outputDir
)
.toTransform(ArtifactType.APK)

It set this
Input folder: app\build\outputs\apk\debug
Output folder: app\build\intermediates\apk\debug\debugUpdateAPKArtifact

- output folder is inside of intermediates instead of input one
- also here I would expect that the output folder will be the same as the normal output folder for APK without transformation (for last one transformation in the chain). Why another level of the hierarchy?

There is one more unexpected thing that

val artifacts = builtArtifactsLoader.get().load(inputDir.get())
artifacts?.elements?.forEach {
it.outputFile is just String. I would expect File there.

Build: AI-202.7660.26.42.6987402, 202011210045,

AI-202.7660.26.42.6987402, JRE 11.0.8+10-b944.6842174x64 JetBrains s.r.o, OS Windows 10(amd64) v10.0 , screens 2560x1440, 2560x1440

AS: 4.2 Beta 1; Kotlin plugin: 1.4.20-release-Studio4.2-1; Android Gradle Plugin: 4.2.0-beta01; Gradle: 6.7; NDK: from local.properties: (not specified), latest from SDK: (not found); LLDB: pinned revision 3.1 not found, latest from SDK: (package not found); CMake: from local.properties: (not specified), latest from SDK: (not found), from PATH: (not found)

IMPORTANT: Please read

https://developer.android.com/studio/report-bugs.html carefully and supply all required information.

MyApplicationKotlin.zip

199 KB

Download

Comments

xa...@google.com <xa...@google.com> Dec 3, 2020 06:55AM

Assigned to je...@google.com.

to...@gmail.com <to...@gmail.com> #2Jan 4, 2021 03:46PM

Thanks for the report. I will route this to the appropriate internal team and update this when I hear back from them.

je...@google.com <je...@google.com> #3Jan 4, 2021 04:05PM

One more detail, Data Layer event calls from the watch to the phone (running Android 13) do work on if the listener is in an Activity or Fragment.

to...@gmail.com <to...@gmail.com> #4Jan 4, 2021 06:06PM

Also, I'm seeing this message in the Logcat:

"2022-06-12 18:47:15.156 1841-4562/? W/PackageManager: Intent does not match component's intent filter: Intent { act=com.google.android.gms.wearable.BIND_LISTENER"

ds...@gmail.com <ds...@gmail.com> #5Jun 21, 2021 11:02PM

Experiencing the same issues, please see my other report for any useful logs:

https://issuetracker.google.com/issues/235673375

je...@google.com <je...@google.com> #6Jun 22, 2021 03:48AM

+1, can confirm it doesn't work on Android 13:=

2022-07-15 11:26:15.023   589-5347  PackageManager          pid-589                              W  Intent does not match component's intent filter: Intent { act=com.google.android.gms.wearable.BIND_LISTENER cmp=xxx/xxx.WatchMessageReceiver }
2022-07-15 11:26:15.023   589-5347  PackageManager          pid-589                              W  Access blocked: ComponentInfo{xxx/xxx.WatchMessageReceiver}
2022-07-15 11:26:15.023   589-5347  ActivityManager         pid-589                              W  Unable to start service Intent { act=com.google.android.gms.wearable.BIND_LISTENER cmp=xxx/xxx.WatchMessageReceiver } U=0: not found

ds...@gmail.com <ds...@gmail.com> #7Jun 22, 2021 07:48AM

Note that I've been able to make it work by:

Adding <action android:name="com.google.android.gms.wearable.BIND_LISTENER" /> in the intent filter
Removing <data android:scheme="wear" android:host="*" />

But I feel like this is not something we should do

je...@google.com <je...@google.com> #8Jun 22, 2021 05:40PM

I'm really afraid Android 13 might get released as-is, breaking WearOS app communication 😨😨

ds...@gmail.com <ds...@gmail.com> #9Jun 22, 2021 08:46PM

If you're not targeting API 33 you're not affected by the bug. So it's a big bug, and yes we of course expected more from Google, but you can always target the api level later when it's fixed.

But I agree this is kind of desperating that more than 1.5 month after the first report nothing has changed.

je...@google.com <je...@google.com> #10Jul 29, 2022 10:14PM

Reassigned to al...@google.com.

As an interim update on this issue: we've been already working on the fix that should be available by Android 13 release. The fix requires thorough testing, I'll keep this bug updated as soon as we have more to share. Thanks!

al...@google.com <al...@google.com> Jul 31, 2022 12:14AM

Accepted by al...@google.com.

je...@google.com <je...@google.com> #11Aug 1, 2022 08:43PM

@comment#9 The Play Store will eventually require targeting API 33, then 34, etc, so accepting this regression in a customer release would be a time ticking bomb for Wear OS apps.

Thank you for the update @comment#10

al...@google.com <al...@google.com> #12Aug 5, 2022 08:00PM

Hey @

comment#10

, do you have any news to share?

Android 13 is out today and we still have no patch unlike what you said a month ago

al...@google.com <al...@google.com> #13Sep 2, 2022 08:12PM

I have no words for this. Android 13 is labeled "stable" but the Wearable API just doesn't work. Can't this issue be given higher priority? If you want to push WearOS you need to make sure it works normally.

al...@google.com <al...@google.com> Sep 16, 2022 07:48PM

Marked as fixed.

to...@gmail.com <to...@gmail.com> #14Oct 31, 2022 03:57PM

This issues has been already given high priority (updated external priority on this bug to reflect internal status). The fix is on the way and going through the final rounds of testing, so the roll out is slated to next couple of weeks.

To reiterate what have been mentioned earlier on this bug: this issue affects only apps targeting Android 13, so the apps won't break unless you bump targetSDK version to 33. In case if you want to start working on app compatibility for Android 13 behaviour changes, you could use Compatibility framework to toggle on/off the changes individually for isolated testing.

to...@gmail.com <to...@gmail.com> #15Jan 21, 2023 10:08PM

comment#14

as much as I agree that is not a blocking bug, you need to understand that:
- The report is 2 months old
- Google chose to release Android 13 with that bug
- There's no mention of this bug on the documentation so you can totally bump your targetSdk without noticing it

So thank you guys for working on this but it's still not a valid excuse for taking that long for such an important issue. Now that being said, let us know when a fix is available