Feature request: documented non-UI configuration for fleet/headless installs (drawer + preferences)

[djbclark]

Problem

We run AutoJs6 as an unattended watchdog on a small device fleet (Termux + Shizuku + wireless ADB). First-time setup must enable several drawer toggles and permissions without human taps:

• Accessibility service
• Foreground service (background stability)
• Shizuku access
• Post notifications, storage, battery-unrestricted, display-over-other-apps
• Off: floating button, pointer location, client/server mode, keep-screen-on-in-foreground

Today we automate this with Mac-side UI automation (uiautomator + drawer scrolling). That is fragile (OEM Settings flows, scroll position, localization) and slow.

What we tried

1. adb shell settings put secure enabled_accessibility_services — works for system accessibility (append-only), but does not set in-app drawer prefs.
2. Reading/writing SharedPreferences — release APK is not debuggable; adb shell uid 2000 gets Permission denied on /data/data/org.autojs.autojs6/.
3. Shizuku shell — same data-dir restriction for normal installs.
4. In-app storages module — script-local only; does not configure app drawer/settings.

Preference keys exist in strings.xml (e.g. key_$_foreground_service, key_$_floating_menu_shown, key_$_enable_a11y_service_with_secure_settings) but there is no documented, supported way to set them outside the UI.

Request

Please consider one or more of:

1. Document default SharedPreferences file name + keys for drawer toggles (and whether adb/run-as / Shizuku is expected to work on release builds).
2. Intent or ContentProvider to apply a named profile, e.g. org.autojs.autojs6.APPLY_FLEET_PROFILE with extras or a JSON file path on shared storage.
3. Export/import settings (XML/JSON) like other Android apps.
4. Optional install-time defaults via intent extra on first launch (e.g. foreground service ON for automation-only deployments).
5. Read-only query API so external tooling can verify state without UI scraping.

Our use case

• Open-source fleet orchestration: stayturgid (AutoJs6 secondary layer; Termux-primary repair; Overall orchistration primarly via ansible, and trying to get as near to being a 100% ansible project as possible).
• Devices: Pixel / Samsung, Android 14–16, Obtainium-installed release APK (v6.7.x arm64).
• We already use Shizuku API from scripts; a Shizuku-guarded preference writer would be acceptable.

Workaround today

UI automation in enable_autojs6_shizuku.py + shared/autojs6_drawer_defaults.json. Happy to contribute docs or a reference profile JSON if an official schema exists.

[djbclark]

I've put together an implementation for non-UI fleet profile configuration.

Branch: https://github.com/djbclark/AutoJs6/tree/feature/fleet-profile-553

What it does:

• New exported activity FleetProfileActivity responds to org.autojs.autojs6.action.APPLY_FLEET_PROFILE.
• FleetProfileApplier reads a JSON profile from a file path or content URI and writes values to AutoJs6's default SharedPreferences.
• Supports boolean, string, int, long, float, and string-array values.
• Includes an alias table so profiles can use short names like foreground_service, floating_menu_shown, enable_a11y_service_with_secure_settings, etc.
• Bundled default profile at app/src/main/assets/fleet_profile_default.json for unattended watchdog deployments.
• Documentation in docs/FLEET_PROFILE.md with am start examples.

Example invocation:

adb shell am start -a org.autojs.autojs6.action.APPLY_FLEET_PROFILE \
    -e profile_path /sdcard/autojs6-fleet.json \
    org.autojs.autojs.core.pref.fleet.FleetProfileActivity

Note: I couldn't run a full Android build locally because the Android SDK isn't set up in this environment, so the code should be reviewed/compiled before merging. Happy to iterate based on feedback.

[djbclark]

Test build binaries for this feature are now available on my fork:

🔗 https://github.com/djbclark/AutoJs6/releases/tag/v6.7.0-fleet-profile-553-debug

These are debug APKs built from the fleet-profile-553 branch (includes the recent build fixes). I’ll be testing them over the next few days and will update this issue with the results — likely within a week.

If anyone else wants to try them out in the meantime, feedback is welcome.

[djbclark]

Test results for the fleet-profile build (build #2, version code 3806):

Build environment

• JDK 25 (downgraded from 26 after the build warned about JDK-26 compatibility)
• Android SDK 36, NDK 26.1.10909125, CMake 3.22.1
• Built from: https://github.com/djbclark/AutoJs6/tree/feature/fleet-profile-553 (now at 453ac8f)

Devices tested

• Samsung Galaxy S24 (Android 16)
• Google Pixel 7a (Android 16)
• Amazon Kindle Fire HD 8 (Fire OS 11 / Android 11)

What was tested

1. Fresh install of the debug APK on all 3 devices.
2. Applied a test fleet profile via the exported FleetProfileActivity using the action intent:
   adb shell am start -a org.autojs.autojs6.action.APPLY_FLEET_PROFILE -e profile_path /sdcard/.../fleet_profile.json -n org.autojs.autojs6/org.autojs.autojs.core.pref.fleet.FleetProfileActivity
3. Verified that the resulting SharedPreferences matched the profile.
4. Applied a second profile to flip several booleans back and verified those changes too.
5. Launched the main AutoJs6 activity and confirmed the app starts without crashing.

Bug found and fixed during testing
The bundled fleet_profile_default.json uses human-readable list values like "timed_task_backend": "alarm". The applier stored these literally, so the app crashed on startup with RuntimeException: Unknown backend: alarm. Fixed in 453ac8f by adding valueAliasToKey mapping in FleetProfileApplier so profiles stay readable while the internal stored values are the real ListPreference keys (e.g. key_\$_timed_task_backend_alarm).

Updated binaries
https://github.com/djbclark/AutoJs6/releases/tag/v6.7.0-fleet-profile-553-debug-2

I'll keep running the watchdog/repair cycle over the next few days and update this issue if anything else shows up.