Status Update
Comments
fl...@google.com <fl...@google.com> #2
kr...@gmail.com <kr...@gmail.com> #3
for the "out" bundle issue, this seems indeed an issue. for the second one reported adding "debugUpdateAPKArtifact" to the path, this WAI as there can more more than one transformer and we need to automatically separate them so they do not use the same output folder. for #3, I will look at it but it might be difficult to change it at this time.
kr...@gmail.com <kr...@gmail.com> #4
go...@stijnvandewater.nl <go...@stijnvandewater.nl> #5
Hello, this is a P1 S1 issue for a while now, and it's blocking us from upgrading to AGP 4.2 and further. What's the current status? And do you have plans to backport it to 4.2.x?
be...@gmail.com <be...@gmail.com> #6
no we don't have a plan to backport this. why is this blocking you from upgrading ?
be...@gmail.com <be...@gmail.com> #7
We sign apk's and bundles via internal service, and i don't know another way to interact with artifacts;
Yesterday i ended up with some ugly workaround:
lo...@gmail.com <lo...@gmail.com> #8
I commented on the merge request but to summarize :
you can set your signing tasks output folder to wherever you need to be :
artifacts.use(target.tasks.signedApkTaskProvider(this)).configure { signedDirProperty.set(File("/path/to/where/you/want/your/signed/files")) }
if you don't set it, then we will set a directory automatically.
be...@gmail.com <be...@gmail.com> #9
Thanks, Jerome!
ks...@google.com <ks...@google.com> #10
I checked that we do have correct behavior for FILE based artifacts like bundle :
> Task :app:debugUpdateArtifact
originalArtifact: /usr/local/google/home/jedo/src/studio-main/out/apiTests/Kotlin/bugTest/app/build/intermediates/bundle/debug/signDebugBundle/app-debug.aab
updatedArtifact: /usr/local/google/home/jedo/src/studio-main/out/apiTests/Kotlin/bugTest/app/build/outputs/bundle/debug/app-debug.aab
however, we still seem to not be consistent for the DIRECTORY based artifacts like APK:
> Task :app:debugUpdateAPKArtifact
Input folder: /usr/local/google/home/jedo/src/studio-main/out/apiTests/Kotlin/bugTest/app/build/outputs/apk/debug
Output folder: /usr/local/google/home/jedo/src/studio-main/out/apiTests/Kotlin/bugTest/app/build/intermediates/apk/debug
Input file: /usr/local/google/home/jedo/src/studio-main/out/apiTests/Kotlin/bugTest/app/build/outputs/apk/debug/app-debug.apk
Alex, can you have a look ?
lo...@gmail.com <lo...@gmail.com> #11
correction, I was not correct about FILE being correct.
Instead of :
updatedArtifact: /usr/local/google/home/jedo/src/studio-main/out/apiTests/Kotlin/bugTest/app/build/outputs/bundle/debug/app-debug.aab
it should be
updatedArtifact: /usr/local/google/home/jedo/src/studio-main/out/apiTests/Kotlin/bugTest/app/build/outputs/app-debug.aab
``
be...@gmail.com <be...@gmail.com> #12
Two requests are created as they are API changes
go...@stijnvandewater.nl <go...@stijnvandewater.nl> #13
Fix will be available in Android Studio F/AGP 8.0 Canary 2 Release
ks...@google.com <ks...@google.com> #14
I tried to use it and at first look, it looks like everything works as expected. Thanks!
be...@gmail.com <be...@gmail.com> #15
The big issue is, that the current AGP 7.4.0 is broken. I tried to use this API and it is still broken in 7.4.0, it is probably really in AGP 8 :-(
kr...@gmail.com <kr...@gmail.com> #16
be...@gmail.com <be...@gmail.com> #17
That must be some really intense testing as we are 10 days later and still nothing on sight. I don't want to be a P2 issue if that's what a P1 is.
ga...@chargepoint.com <ga...@chargepoint.com> #18
[Deleted User] <[Deleted User]> #19
kr...@gmail.com <kr...@gmail.com> #20
be...@gmail.com <be...@gmail.com> #21
My bet is that Google still targets API 32 (or even lower) internally so they don't care and didn't even saw the issue before our report.
[Deleted User] <[Deleted User]> #22
ks...@google.com <ks...@google.com> #23
This issue is fixed. The fix has been rolled out via GMSCore and will also require using the latest com.google.android.gms:play-services-wearable:18.0.0
release.
Note that you don’t need to add BIND_LISTENER
manually, it has been deprecated for a long time and it continue to remain so (read more at
Appreciate all the feedback and patience.
ru...@gmail.com <ru...@gmail.com> #24
be...@gmail.com <be...@gmail.com> #25
Hey @com.google.android.gms:play-services-wearable:18.0.0
.
After 4 months of testing, it looks like it's broken.
kr...@gmail.com <kr...@gmail.com> #26
be...@gmail.com <be...@gmail.com> #27
Well that's possible but I've tested things carefully and targetting API 32 immediately fixes the behavior so I'm confident this is the root cause of the issue
lo...@gmail.com <lo...@gmail.com> #28
Can you share the configuration code you have for the affected service from your AndroidManifest.xml
file?
be...@gmail.com <be...@gmail.com> #30
lo...@gmail.com <lo...@gmail.com> #31
Are you 100% sure that the apk deployed was not an old one with the
old library version for example?
Since there's been some issues with that in past Android Studio versions
and AGP, and since I'm not sure if it's fully fixed and which versions did,
I'd try to run the clean Gradle task, and then run the install task from
command line, and also make sure you're not trying the wrong
buildType/variant.
Please keep us updated.
On Sun, Oct 23, 2022 at 3:56 PM <buganizer-system@google.com> wrote:
be...@gmail.com <be...@gmail.com> #32
I don't think it's that, it was installed from PlayStore so it's a release one built from command line with a version bump
Maybe there was something wrong but all I did between this build and the new one is roll back to targeting API 32 and things worked immediately so it's strange to me.
to...@gmail.com <to...@gmail.com> #33
As a reminder the fix require an update to Play Services on the device too.
be...@gmail.com <be...@gmail.com> #34
Indeed I can see PlayServices aren't updated on my device, like on a lot of Android devices right now auto-update of apps is broken.
I'll try again with up to date services and I'll let you know.
But that means it's far from production ready as we can't expect all of our users to be up to date right now so I'm glad I rollbacked to API 32 for now.
lo...@gmail.com <lo...@gmail.com> #35
Which Play Services version is supposed to fix it? We might add a check using PackageManager APIs to direct users to perform the update.
sw...@gmail.com <sw...@gmail.com> #36
li...@gmail.com <li...@gmail.com> #37
Have you taken into account the situation of Chinese devices? It's hard for them to upgrade the Play Service and there are no official solutions about this issue.
ol...@gmail.com <ol...@gmail.com> #38
ol...@gmail.com <ol...@gmail.com> #39
=======
"Status
You won't be able to release app updates (11 days away)
Date sent
Aug 10, 2023
Deadline
Aug 30, 2023
Violation
App must target Android 13 (API level 33) or higher"
[Deleted User] <[Deleted User]> #40
Issue is not yet solved, as we face the exact same problem still.
- Using
targetSdk=31
andcom.google.android.gms:play-services-wearable:18.1.0
: OK - Using
targetSdk=33
andcom.google.android.gms:play-services-wearable:18.1.0
: NOT OK
When using targetSdk 33, messages are no longer sent from the wearable to the phone (e.g. WearableListenerService.onMessageReceived()
) is no longer called.
ja...@gmail.com <ja...@gmail.com> #41
com.google.android.gms:play-services-wearable:18.1.0
ha...@gmail.com <ha...@gmail.com> #42
yf...@gmail.com <yf...@gmail.com> #43
You do not have the Arabic language. I am not fluent in English
ch...@gmail.com <ch...@gmail.com> #44
da...@gmail.com <da...@gmail.com> #45
1.1.5.2.5.2.5.1.5.4.4.2
Description
Sample app:
Install both the phone and watch app then open the phone app. In the Logcat of the phone app you should see "test" outputted. If the target SDK is set to 32, you will see the message.
Phone Bug Report:
Watch Bug report:
This has been tested on:
Pixel 5
Android 13 Beta 3.
WearOS 2.34
WearOS System Version: H M2