Connection config + the single source of truth for protocol/connection defaults.

There are two kinds of configuration:

1. Per-connection config — passed to Amarula.new/1

A map; you supply only what differs (at minimum :profile), merge/1 fills the rest from the defaults below.

Amarula.new(%{profile: :me, sync_full_history: false}) |> Amarula.connect()

Android browser mode (impact)

Setting an Android :browser (e.g. ["MyApp", "Android", ""]) registers the linked device as an Android client rather than WhatsApp Web. This changes the registration/login payload in three ways (mirroring Baileys #2201):

• ClientPayload.userAgent.platform becomes :ANDROID (not :WEB).
• webInfo is omitted (it's a web-client field).
• DeviceProps.platformType becomes :ANDROID_PHONE.

Why you'd opt in: an Android-registered session can receive view-once media that a Web session cannot.

Costs / caveats — opt in deliberately:

• Experimental. This is a newer, less-exercised WhatsApp path; upstream labels it experimental ("use at your own risk"). It may behave unexpectedly or be tightened by WhatsApp.
• The device shows as a phone/Android client, not a desktop browser, in the user's "Linked devices" list.
• Default (any non-Android :browser) is unchanged — full Web behaviour, webInfo sent, platform: :WEB. Existing configs are unaffected.

2. App-global config — config :amarula, ...

Two knobs are read from application env instead of per-connection: which backend module is the default for storage and for the retry-cache. They're process-wide policy — set once for the whole app — and any connection can still override them by naming its own {module, opts} in :storage / :retry_cache above. Everything else is per-account and lives on the Conn, not here.

config :amarula, :default_storage_adapter, Amarula.Storage.File
config :amarula, :retry_cache_adapter, Amarula.RetryCache.ETS

These point at behaviours you can implement yourself to decide where this state lives (disk, DETS, Postgres, S3, Redis, …):

• Amarula.Storage — durable auth/session/mapping state. Losing it means re-pairing from a QR, so back it up; see the callbacks + namespaces there, and docs/GOING_PROD.md for choosing/writing an adapter.
• Amarula.RetryCache — short-lived sent-message cache for retry/decrypt recovery; safe to lose (it self-heals), so an in-memory ETS default is fine.

Logging

Amarula logs through Elixir's Logger. Almost everything is :debug; only connection lifecycle, pairing, and errors are :info/:warning/:error. To keep your dev console clean, set the global level — or silence Amarula specifically without affecting your own logs:

# your app's config
config :logger, level: :info

# or, mute just Amarula (Elixir 1.13+):
Logger.put_module_level(Amarula.Connection, :warning)

Telemetry (Amarula.Telemetry) is the structured, log-independent way to observe Amarula in production.