[SmarthomeElektroniker]

Problem

When a device page is opened, the Android app calls GET /api/v1/checkAppAgreement. The request ends up in the catch-all. The app deserializes the response as UserAgreementInfoV1:

{
  "userAndPrivacyAgree": true,
  "improvementPlanAgree": true,
  "recommendationAgree": true,
  "userPluginAgreementList": [
    {"deviceId": "<duid>", "type": 1, "version": 1, "extra": ""}
  ]
}

Every field has a default, so the catch-all object does not fail. It silently becomes "nothing agreed" with an empty plugin agreement list. The app log then shows

RR/UserPreferenceRepository: checkAgreementV1 pluginAgreements:
RR/UserPreferenceRepository: getPluginAgreements no data <duid>

Then the device plugin stops making requests, and the map stays on "loading". The plugin's last native calls before it goes silent are getProductAgreements, getPluginAgreements (empty list) and readFileListAtPath. After that, the plugin sends no further request.

The field names come from the app's UserAgreementInfoV1 serializer and from UserPreferenceRepository$getPluginAgreements (deviceId, type, version, extra).

Fix

New route routes/api/v1/agreement.py (check_app_agreement_v1):

• reports the three app agreements as accepted
• reports one plugin agreement per home device and agreement type

Caveat: we do not know the full set of valid type values. The app keeps this list as a raw JSON element and passes it to the plugin. Types 1–3 with version 1 are enough for the plugin to get past this check. If you know the real values from a cloud capture, they are easy to swap in (PLUGIN_AGREEMENT_TYPES).

Tests

tests/test_check_app_agreement.py

• all agreements accepted, entries with the expected keys and types for every paired device
• no paired devices gives an empty plugin agreement list

Full suite: passing.

Live check (Oct 2026): verified together with the other fixes of this series (all based on current main) against the Android app 4.60.06 and a real Q7 Max (roborock.vacuum.a38). The app called /api/v1/checkAppAgreement (now served by the new route). The device plugin got past its agreement check and went on to fetchDeviceLocation, with no privacy dialog.

Notes

This route removes the server-side cause of the "no data" log. Map loading can also depend on app-side factors I could not isolate, so I can't promise that this route alone makes the map load in every setup.

🤖 Generated with Claude Code

[Lash-L]

I believe this should be strings.

PLUGIN_AGREEMENT_TYPES = ("USER_AGREEMENT", "PRIVACY_POLICY")

I believe.

[SmarthomeElektroniker]

You're right, thanks. I checked the app: UserPreferenceRepository.getPluginAgreements reads each entry's type as a string (JsonPrimitive.content), and both the a38 plugin bundle and the app's AgreementInfo bean use the constants USER_AGREEMENT and PRIVACY_POLICY. The placeholder integers only worked because the plugin didn't reject the unknown values.

Changed in effc85a: PLUGIN_AGREEMENT_TYPES = ("USER_AGREEMENT", "PRIVACY_POLICY"), test updated accordingly.