Status Update
Comments
bl...@google.com <bl...@google.com> #2
sh...@fieldking.com <sh...@fieldking.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.
sb...@google.com <sb...@google.com> #4
sh...@fieldking.com <sh...@fieldking.com> #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?
sh...@fieldking.com <sh...@fieldking.com> #6
sh...@fieldking.com <sh...@fieldking.com> #7
jp...@google.com <jp...@google.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.
sh...@fieldking.com <sh...@fieldking.com> #9
sh...@fieldking.com <sh...@fieldking.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 ?
sb...@google.com <sb...@google.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
``
jp...@google.com <jp...@google.com> #12
Two requests are created as they are API changes
sh...@fieldking.com <sh...@fieldking.com> #13
sh...@fieldking.com <sh...@fieldking.com> #14
sh...@fieldking.com <sh...@fieldking.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 :-(
sh...@fieldking.com <sh...@fieldking.com> #16
sh...@fieldking.com <sh...@fieldking.com> #17
sh...@fieldking.com <sh...@fieldking.com> #18
jp...@google.com <jp...@google.com> #19
The sample code I shared will need to be modified to work with the oauth pattern used in your code. Additionally, you may need to add some scopes.
sh...@fieldking.com <sh...@fieldking.com> #20
sh...@fieldking.com <sh...@fieldking.com> #22
sh...@fieldking.com <sh...@fieldking.com> #23
sh...@fieldking.com <sh...@fieldking.com> #24
sb...@google.com <sb...@google.com> #25
This issue is closed and no further responses on this issue will be given. Please see the above resources for details on how to implement oauth.
Description
Hey team,
I'm using the Google Meet API to schedule meetings, but I'm encountering an issue when inviting participants with non-Gmail accounts. For instance, if I invite two people—one with a Gmail account and the other without—the non-Gmail user is unable to join the meeting directly. Instead, they are prompted to request permission to join, which can be inconvenient. While I'm aware of the option to manually adjust host controls to allow all users, doing this for each meeting is impractical and tedious. Is there a way to configure the API so that host controls are automatically open for all users, regardless of their email domain?