Status Update
Comments
ar...@gmail.com <ar...@gmail.com> #2
[Deleted User] <[Deleted User]> #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.
li...@gmail.com <li...@gmail.com> #4
[Deleted User] <[Deleted User]> #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?
xu...@gmail.com <xu...@gmail.com> #6
no we don't have a plan to backport this. why is this blocking you from upgrading ?
jo...@gmail.com <jo...@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:
st...@whitecobalt.com <st...@whitecobalt.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.
gm...@gmail.com <gm...@gmail.com> #9
Thanks, Jerome!
ma...@allos.it <ma...@allos.it> #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 ?
as...@gmail.com <as...@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
``
nv...@gmail.com <nv...@gmail.com> #12
Two requests are created as they are API changes
pi...@gmail.com <pi...@gmail.com> #13
Fix will be available in Android Studio F/AGP 8.0 Canary 2 Release
dd...@frata.io <dd...@frata.io> #14
I tried to use it and at first look, it looks like everything works as expected. Thanks!
sa...@gmail.com <sa...@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 :-(
ma...@allos.it <ma...@allos.it> #16
ar...@gmail.com <ar...@gmail.com> #17
as...@gmail.com <as...@gmail.com> #18
si...@dudgeon.fi <si...@dudgeon.fi> #19
fa...@gmail.com <fa...@gmail.com> #20
fa...@gmail.com <fa...@gmail.com> #21
fa...@gmail.com <fa...@gmail.com> #22
I think this bug is related to the fact that Google is fighting against people who are trying to spam the calendars, I hope they will solve the issue soon..
sa...@gmail.com <sa...@gmail.com> #23
ma...@allos.it <ma...@allos.it> #24
ar...@gmail.com <ar...@gmail.com> #25
dr...@googlemail.com <dr...@googlemail.com> #26
si...@dudgeon.fi <si...@dudgeon.fi> #27
as...@gmail.com <as...@gmail.com> #28
mi...@xpsnote.com <mi...@xpsnote.com> #29
I'm not sure all that is involved in recoding to switch to a user account, but it seems like the service calendar issue should be fixed regardless.
Has anyone been able to get their service calendars to work again?
ja...@google.com <ja...@google.com>
ja...@google.com <ja...@google.com> #30
Thanks for your report! We are aware there is an issue with Calendar and Service Accounts and we are working on it to fix it as soon as possible. You can click on the star ☆ next to the issue number to receive updates and give more priority to this post.
Cheers!
ar...@gmail.com <ar...@gmail.com> #31
fe...@bellizia.com <fe...@bellizia.com> #32
si...@dealdash.com <si...@dealdash.com> #33
ug...@gmail.com <ug...@gmail.com> #34
jb...@gmail.com <jb...@gmail.com> #35
It does not work for me
ar...@gmail.com <ar...@gmail.com> #36
ma...@allos.it <ma...@allos.it> #37
ar...@gmail.com <ar...@gmail.com> #38
[Deleted User] <[Deleted User]> #39
Uncaught exception: quotaExceeded: Calendar usage limits exceeded.
[Deleted User] <[Deleted User]> #40
The requests without attendees in them are working, but any requests with attendees in them keep returning this error even with exponential backoff.
code: 403,
errors: [ { domain: 'usageLimits',
reason: 'quotaExceeded',
message: 'Calendar usage limits exceeded.' } ] }
using official nodeJS googleAPIs node module, also sending quotaUser with each request as well!
Is this behavior intended? Is there some sort of limit that isn't documented well?
Description
Also, I shared the calendar with "normal" google account, so I can also add events to that calendar manually.
Recently i Noticed notifications are no longer sent from that calendar (which belongs to the google service account). Tried both by calling the API and manually using google calendar UI.
What i'm missing? Any recent changes to the calendar API can cause this?