Android: support custom host vitals in configuration profiles

[nulmete]

Goal

User story
As a Fleet user,
I want to use custom host vitals (e.g. asset tag, Jamf device ID) as variables ($FLEET_HOST_VITAL_<id>) in Android configuration profiles — the same way they already work in scripts and Apple/Windows configuration profiles
so that I can inject per-host vitals that aren't otherwise available into Android managed configurations.

Context

Custom host vitals shipped in #44954 with support in scripts, Apple configuration profiles, Apple DDM declarations, Windows configuration profiles, and setup-experience/software-installer scripts. Android was explicitly deferred at that time: $FLEET_HOST_VITAL_<id> is rejected on upload for Android profiles, to keep parity with $FLEET_SECRET_ (which also rejects Android at upload). This story lifts that restriction for custom host vitals.

Likely scope (to be finalized during grooming):

• Remove the Android upload-time rejection/validation for $FLEET_HOST_VITAL_<id>.
• Add per-host $FLEET_HOST_VITAL_<id> expansion in the Android managed-config delivery path (mirroring the existing Apple/Windows expansion).
• Add a "resend on value change" trigger for Android profiles — the current per-host-value resend (resendMDMProfilesForCustomHostVital) deliberately omits Android, so a host's value change wouldn't re-deliver Android profiles until this is added.

Open question for product: $FLEET_SECRET_ has the same Android upload rejection today. Decide whether secrets should get Android parity at the same time, or whether custom host vitals diverge from secrets here.

Changes

Product

• UI changes: No changes
• CLI (fleetctl) usage changes: No changes
• YAML changes: No changes
• REST API changes: No changes
• Fleet's agent (fleetd) changes: No changes
• Fleet server configuration changes: No changes
• Exposed, public API endpoint changes: No changes
• fleetdm.com changes: No changes
• GitOps mode UI changes: No changes
• GitOps generation changes: No changes
• Activity changes: No changes
• Permissions changes: No changes
• Changes to paid features or tiers: No changes
• My device and fleetdm.com/better changes: No changes
• Usage statistics: No changes
• Other reference documentation changes: No changes
• First draft of test plan added
• Once shipped, requester has been notified
• Once shipped, dogfooding issue has been filed

Engineering

• Test plan is finalized
• Feature guide changes: Update the Custom host vitals guide — remove Android from the "coming soon" note (now shipped: "Support for custom host vitals in Android configuration profiles and host name templates is coming in Fleet 4.91." becomes "Support for custom host vitals in host name templates is coming in Fleet 4.91."), and update the resend-on-value-change description to mention Android alongside Apple/Windows.

ℹ️ Please read this issue carefully and understand it. Pay special attention to UI wireframes, especially "dev notes".

Risk assessment

• Requires testing in a hosted environment: No
• Requires load testing: No
• Risk level: Low
• Risk description: Additive change gated behind Android MDM already being configured; existing Android profiles/app configs without vital references are unaffected (validation and substitution both early-return when no $FLEET_HOST_VITAL_ token is present). No database schema changes. Mirrors the exact validation/expansion/resend pattern already shipped and tested for Apple and Windows in Add/edit/delete custom host vitals #44954

Test plan

Make sure to go through the list and consider all events that might be related to this story, so we catch edge cases earlier.

Core flow

1. Using an existing custom host vital (e.g. "Asset tag"), add an Android configuration profile that references $FLEET_HOST_VITAL_<id> inside a string value, and assign it to a team with an enrolled Android host. Confirm the profile is now accepted at upload (previously rejected with "Custom host vitals aren't supported in Android configuration profiles").
2. Before a value is set for the host, confirm the profile shows Failed on that host, with detail "...no value set for this host".
3. Set the host's value for the vital (host details page, or PUT /api/v1/fleet/hosts/:id/custom_host_vitals/:id).
4. Confirm the profile automatically resends and installs successfully on the host, with the vital correctly substituted in the delivered policy (verify via the host's profile detail, or the Android Enterprise admin console if available).
5. Edit the vital's value again. Confirm the profile automatically resends and re-delivers with the updated value.
6. Repeat steps 1–5 using an Android app's managed app configuration (a VPP/Android software title's "Configuration" field) instead of a configuration profile.
7. Repeat the upload in step 1 via GitOps (fleetctl gitops) to confirm the batch path accepts the vital reference the same way as the single-profile UI/API upload.

Edge cases

• Uploading an Android configuration profile or managed app configuration referencing a custom host vital ID that doesn't exist is rejected, for both single upload and GitOps/batch.
• Uploading an Android configuration profile or managed app configuration with a malformed vital reference (e.g. $FLEET_HOST_VITAL_asset_tag) is rejected.
• Referencing $FLEET_HOST_VITAL_<id> as a JSON key (not inside a string value) in an Android configuration profile is rejected at upload.
• Deleting a custom host vital that's still referenced by an Android configuration profile is blocked with a "used by" error, the same as for Apple/Windows profiles and scripts.
• A vital referenced by profiles/hosts across multiple platforms: changing its value on one host resends only the Apple/Windows/Android profiles/hosts that actually reference it — unrelated hosts and profiles are left untouched.

Supplemental testing

Testing notes

Confirmation

1. Engineer: Added comment to user story confirming successful completion of test plan (include any special setup, test data, or configuration used during development/testing if applicable).
2. QA: Added comment to user story confirming successful completion of test plan.
3. QA: Determined whether this story needs Playwright automation.
   • Needs automation: Yes / No
   • If yes, filed a follow-up issue in the :help-qa project with status "Needs automation":

[noahtalerman]

Thanks for tracking this @nulmete! Can you please help us fill out the TO - DOs in the "Product" and "Engineering" sections?

Also, heads up that I added the 4.91 milestone assuming we're bringing this into the next sprint. Up to @rachaelshaw on if that's the right timing. Up to @sharon-fdm on if it fits.