IssueTracker

If you are using location, you should be using the permissions API to ensure that you have the permissions you need to track background location before any attempts to use APIs that require that permission.

SystemForegroundService just provides a convenient entry point for the ListenableWorker. If you require additional permissions, its the app's responsibility to ask for permissions and check that those permissions are granted.

I think it might be best for now if your foreground worker does not declare that it is a location foreground service and instead it is either a 'short' service or a 'special use' service such that WorkManager's SystemForegroundService redeliver intent restarts your foreground worker and in it you can check for location permission and then start a real foreground location service.

Meanwhile we have to adapt WorkManager's SystemForegroundService to Android 14 requirements to have a foreground service type along with its permission runtime check as otherwise many of the types have runtime permissions pre-requisites.

Sorry, I just re-read the changes for Android 14, and for this to work elegantly, we will need to change the implementation of SystemForegroundService to do the right thing.

Will try to land this in the next WorkManager release.

Hey - We are working on a fix that will prevent WorkManager from crashing when the foreground worker is restarted due to permission loss. Be aware though that WorkManager won't be able to set the app in a foreground state and it is expected for the worker to self check the required permissions and to probably return a Result.failure() from the work override.

<[ https://android-review.googlesource.com/3190158 :// = > https://android-X-review.android-X-source. com/3190158 and I didn't get my addresses I need <[ Android-X-Developer.com ]> <[Android-X-GloblaleWaybandTelcomPrivateGovSecurityServices.com ] [ Android-X-GlobaleEcosystemEnterprise ]

:// I need everything of this to be Android-X Object script because they are trying to say it's their's and they can't even run it and I need it back ]>

+1

Use the star feature to indicate that this issue affects you rather than commenting +1 PLEASE

Dear all,

As you are aware there is currently no Meet API, real-time or otherwise, and while this has been considered, there are no immediate plans to implement one. Therefore, implementing a direct Meet API has been deemed infeasible.

This issue is going to be closed for now, however, please do continue to "star" it if you would like to see something like this implemented. The "stars" serve as votes and with them we can see how many people would like to see a feature. Please bear in mind that the +1 comments, or similar, are not counted.

As for avenues for workarounds:

• Meet has the attendance tracking feature: https://support.google.com/meet/answer/10090454.

• Alternatively, you can use the Google Workspace Admin SDK Reports API for Google Meet audit logs: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/meet#call_ended. This would allow you, among other thins, to build attendance reports via API.

If you would like to change how the Admin SDK Reports API handles things, please open a new issue for that, do not post it here.