Feature Request: Add standby bucket state to MetadataService (and surface it in the embrace dashboard)

[caplan]

It would be very helpful if MetadataService were to capture the app's [standby bucket](https://developer.android.com/reference/android/app/usage/UsageStatsManager#getAppStandbyBucket()). Some of those buckets restrict the app's network access or ability to run jobs.

I could submit a pull request if that's something you'd be open to, although obviously this info needs to be surfaced in the dashboard as well.

[bidetofevil]

Hi @caplan - we are finalizing our issues triage process and contribution guidelines, so we'll get back to you on this as soon as we can. About this feature request specifically, at first glance, it seems like a reasonable thing to have, so we'll discuss this internally (as well as figuring out how we can pull the entire thread through to the UI)

[bidetofevil]

HI @caplan - just a quick non-update 😅

We are still working out the process and issues template stuff, but regarding this specific feature, we are trying to figure out how to best fit this under a new OpenTelemetry-based SDK architectural model. So maybe a couple of questions to clarify what you're look for to see if it meshes about how we are thinking about it:

• Are thing thinking this is a piece of metadata that is tagged with every session, and immutable throughout that session (e.g. similar to disk usage), or something else?
• If it's a session attribute, what other places in the dashboard do you want to see this besides the "Session Information" side bar?
• How crucial is the ability to filter by this attribute?

[bidetofevil]

Hi @caplan - sorry our bot auto-closed this. We are just at the cusp of releasing an API to more easily allow 3rd party instrumentation to be written using just the OTel API. When that happens, we can discuss how this bets fits into the data model

[caplan]

thanks - to answer your earlier questions:

Are thing thinking this is a piece of metadata that is tagged with every session, and immutable throughout that session (e.g. similar to disk usage), or something else?

something else - it's not immutable but unfortunately I don't think android provides any sort of callback that would allow one to track its state change, so the best we could probably do is query for its value at "important moments", like maybe on error?

How crucial is the ability to filter by this attribute?

The particular use case we've run into is when an FCM push notification comes in and reaches the app, which then tries to fetch a thumbnail image to display on the lock screen. The fetch sometimes fails because the app has been placed into a state that allows it to receive FCM notifications but not to open outgoing network connections. Knowing why the app cannot open network connections would help us know how to plan around these situations.

[bidetofevil]

Right. The state will be mutable, but as you said, i think we have to poll to get the data. It's probably reasonable to do so periodically, like once every cold start, and record that somehow, so at least you know that when that particular app instance started, which bucket you're in.

Would a log that is associated with the session be sufficient? If your primary use case is debugging, that might work as you'll be able to tell by looking at the user timeline.

Alternatively, it also makes sense to tag this as a attribute/property of the session, but that will limit how much additional data we can add if Android ever returns more than just the bucket, and we also don't have a good integration story about how this could be done external to the SDK other than as an ad hoc session property.

Would this be of interest to you if you can get this as a log associated with a cold start session?

[caplan]

Would this be of interest to you if you can get this as a log associated with a cold start session?

Yes, having this as a log associated with a cold start session would work I think.

[bidetofevil]

Excellent. We will be building the OTel Logger API integration piece soon, and it make sense to use this as a test case. Stay tuned - and thanks for raising this!