AMS Module Development

AMS Module Development

This page documents the current AMS module format accepted by ModuleManager.

Required Structure

Minimum module zip content:

module-info.json
overlay/

Optional subtrees and scripts:

overlay/system/
overlay/vendor/
overlay/product/
post-fs-data.sh
service.sh

overlay/ must exist, even if only one target subtree is used.

module-info.json Schema

Recognized fields:

• name (required)
• version
• author
• description
• mount (bool, default true)
• post_fs_data (bool, default false)
• service (bool, default false)

Name validation:

• allowed chars: a-z, A-Z, 0-9, -, _, .

Example Module

module-info.json:

{
  "name": "example-fonts",
  "version": "1.0.0",
  "author": "you",
  "description": "Example AMS module",
  "mount": true,
  "post_fs_data": false,
  "service": false
}

Directory tree:

example-fonts/
  module-info.json
  overlay/
    system/
      fonts/
        MyFont.ttf

Packaging

From inside module root:

zip -r ../example-fonts.zip .

Accepted zip layouts:

• flat root (module-info.json at archive root)
• single nested top-level folder containing module root

Installation

apm module-install /path/to/example-fonts.zip

Other lifecycle commands:

apm module-list
apm module-enable example-fonts
apm module-disable example-fonts
apm module-remove example-fonts

Script Behavior

• post-fs-data.sh runs synchronously when post_fs_data is true.
• service.sh runs in background when service is true.
• Script output is appended to /data/ams/logs/<module>.log.

State File

AMS writes state.json in module root with fields:

• enabled
• installed_at
• updated_at
• last_error

Practical Tips

• Keep top-level overlay entries additive and predictable.
• Validate module name early before packaging.
• Check /data/ams/logs/<module>.log after each install/enable cycle.
• Reboot once after major overlay changes if target partitions were not yet mounted when module was enabled.