Config UI has Headwind-style fields (volume/brightness/wallpaper/BT) but they don’t apply on the new agent — expected?

[leenice285-create]

Hi — thanks for MDMesh. We’re evaluating it as a self-hosted Android MDM (Device Owner) alongside classic Headwind Community, and I’d like to confirm the intended product boundary between the console and the new agent.

Context

• Deployed MDMesh locally, enrolled a real rugged Android 12 device as Device Owner (com.mdmesh.agent).
• Remote commands work well for us: device.alert, device.ring, device.lock, kiosk.enter / kiosk.exit, policy.apply (e.g. Bluetooth), command history DONE/FAILED, etc.
• The web Configurations editor still exposes many Headwind-era fields (Display / Network / Restrictions), e.g.:
  • volume / manageVolume
  • brightness / timeout
  • backgroundColor / backgroundImageUrl
  • bluetooth / wifi toggles on the config form
  • free-text restrictions

What we observed

1. Changing those config fields + Save + Sync now often has no effect on the device (volume, screen timeout, launcher wallpaper/background).
2. Bluetooth Off in the configuration UI also did not apply by itself; it only worked after queueing policy.apply with { "policy": "bluetooth", "value": false }.
3. Wallpaper/background color only showed up meaningfully inside kiosk launcher (kiosk.enter + theme.backgroundColor), not as a normal system home wallpaper outside kiosk.
4. So the console looks feature-rich (Headwind-like), but the new agent appears command-centric, and many config fields feel like legacy/unwired UI.

We had assumed “fork of Headwind” might mean at least Headwind’s config-sync policy surface + newer console/commands. Empirically it feels more like:

• server/DB/UI schema retained from Headwind
• agent rewritten around check-in + policy.apply / device actions / kiosk
• config→device reconcile for many Display settings not (yet) implemented on the new agent

Questions for maintainers

1. Is the above understanding correct / intentional for the current stable line (we’re on the v0.2.x agent/console)?
2. Which configuration fields are actually enforced by com.mdmesh.agent today, vs UI-only / legacy?
3. Is there a roadmap to restore Headwind-style config sync for volume, brightness, timeout, wallpaper, and similar “small” policies—or should integrators treat commands + kiosk as the supported path and ignore those config fields for now?
4. For Bluetooth specifically: should admins use config toggles, policy.apply, or both? (Config-alone was insufficient in our test.)

Happy to file a more formal issue if you prefer; a short “supported vs legacy” note in the docs would already help evaluators a lot.

Thanks!