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 Our business case highly depends on being able to list the messages in a dm or room.

Hi there!

The Google Chat API is for bots and thus is limited to the action the bots are able to do. Right now the way of retrieving user messages on a bot is by receiving an event when they are sent (see MESSAGE event). You only receive messages from real (non-bot) users that are either on rooms that the bot has been added, the bot DM, or by messages where the bot has been mentioned.

What use case do you have that requires you to fetch all messages?

Many thanks!

PS: Adding a comment with +1 does absolutely nothing to bring an issue to Google attention. The proper way of doing so is to click at the white star (☆) on the top-left.

Actually, Google Chat has notifications on multiple platforms (read to enable them here).

Also, the Chat API is just for bots (see reference). So if there was a list of messages, it would be the list of the messages of the bot and not your account.

Cheers!

What use case do you have that requires you to fetch all messages?

my case: I use a helpdesk google chat room where any user can send question and any user who knows the answer can help. So I am interesting and trying to chreate chatbot which can find answers in FAQ database and answer automatically. Moreover any should have ability to ask some more detail without mention bot. Seems that ability to receive all new messages in chat is the essential point in this issue. May be option to allow/disallow this feature will be good choice

The features requested

There are 2 kind of features which are a bit different:

1. Allow the bot to interact with other messages. A good example would be to be able to quote other messages with a command.
2. Get the messages on a space (usually a room). This wouldn't need to be bot. A good example would be generating message statistics.

The second request would be a new API and not part of the current one. Also notice that any of the two features could be used to work around the other:

• If the first gets implemented, you would add your bot to read the messages.
• If the second gets implemented, you would be able to make the call when needed.

Possible workarounds

If you need to automate some questions and answers, you can make users to start a chat your bot instead of using a room. The bot will receive all the DMs (even if not mentioned). This would also remove the need to create rooms every time.

Another possibility would be to use Google Vault (read more about it) together with its API to download a space's chat messages (see in which formats) which then could be programmatically read. This won't be instantaneous which means using an asynchronous bot would likely be necessary for feature #1.

Final notes

I've made an internal report on feature #1 as it is the one related to this component. If there are any further updates or inquiries about it, they'll be posted here.

Have a wonderful day!

I am also interested in some sort of chat notification. I realize the browser and phone can be set up for alerts, but I want a big flashing alarm that's impossible to overlook when I have a new chat message.

After realizing the chat api is only for bots and cannot be used unless the messages are addressed to it or a space, I stumbled on the original issue at (https://issuetracker.google.com/issues/169647708) and thought I found a workaround with https://www.googleapis.com/gmail/v1/users/me/labels/CHAT

Even though the unread message count didn't work for the CHAT label, I could just track the current message count and implement a last reviewed count. That lead me to the watch function and creating a pub/sub client to listen for changes in messages.

However, chat message changes are not published. I can send myself a couple chats with no update, but an email will fire one. Then, when I check the message count again, the chat count has indeed incremented along with the inbox count, but without any notification.

So I guess that only leaves polling the gmail api every so often to get a new message count. I was hoping for a more elegant solution, especially when I realized the depth of the Google cloud platform, but it looks like this is it.

Hopefully I've missed something, or something related will come from this feature request.

What use case do you have that requires you to fetch all messages?

I just want to be able to make my own search app that isn't a horrible experience to use on threads that are longer than a page or two.

https://developers.google.com/chat/api/reference/rest/v1/spaces.messages/list