
Build Zoom Meeting Sdk App
Integrate Zoom Meeting SDK on Android with default UI first, then custom UI, auth, and in-meeting modules backed by a signing service.
Overview
Build Zoom Meeting SDK App is an agent skill for the Build phase that guides Android Meeting SDK integration—auth, default UI join, custom UI, and in-meeting modules—with a backend signing layer.
Install
npx skills add https://github.com/anthropics/knowledge-work-plugins --skill build-zoom-meeting-sdk-appWhat is this skill?
- Five-step practical guidance: init/auth, first default-UI join, flags and errors, custom UI only when needed, meeting ca
- Layer model: App UI, meeting orchestration state machine, mobilertc.aar facade, backend signature/JWT service
- Docs validation snapshot spans get-started, integrate, default-ui, custom-ui, error-codes, and API reference maps
- Local package reference: zoom-sdk-android-6.7.5.37500 with mobilertc.aar and sample modules
- Scope covers Android default UI, custom UI, auth, start/join, and in-meeting feature modules
- 5-step practical guidance sequence from init through observability
- Local package checked: zoom-sdk-android-6.7.5.37500 (mobilertc.aar, sample apps, dynamic sample modules)
Adoption & trust: 841 installs on skills.sh; 19.6k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need Zoom meetings inside your Android app but stall on SDK init, token signing, and when to leave default UI versus custom UI.
Who is it for?
Indie Android developers shipping a SaaS or vertical app that must host Zoom meetings in-app with controlled UX.
Skip if: Web-only Zoom embeds, server-side meeting bots with no Android client, or teams skipping a backend signing service.
When should I use this skill?
Embedding Zoom Meeting SDK on Android for default or custom meeting UI, auth, start/join, and in-meeting features with backend signing.
What do I get? / Deliverables
You follow a validated init-join-observe path, wire backend-issued tokens, and extend in-meeting features only after a stable default-UI join.
- Layered architecture plan: UI, orchestration, SDK facade, signing API
- First successful default-UI join checklist with error-code handling
- Observability hooks for meeting status and SDK callback failures
Recommended Skills
Journey fit
Build is correct because the artifact is an Android app integration with SDK init, join flows, and feature modules—not distribution or production monitoring playbooks. Integrations captures third-party SDK wiring, backend JWT/signature service, and callback observability rather than generic frontend polish.
How it compares
Opinionated Android Meeting SDK integration guide—not the Zoom REST scheduling API alone and not a cross-platform Flutter wrapper skill.
Common Questions / FAQ
Who is build-zoom-meeting-sdk-app for?
Solo and small-team Android builders embedding Zoom meetings who need SDK auth, join flows, and optional custom UI without reading the entire Zoom doc tree.
When should I use build-zoom-meeting-sdk-app?
Use it during Build integrations while scaffolding Zoom Android SDK init, backend JWT/signature issuance, first default-UI join, and in-meeting feature modules.
Is build-zoom-meeting-sdk-app safe to install?
Review the Security Audits panel on this page; treat SDK keys and signing endpoints as secrets and never paste production credentials into agent logs.
SKILL.md
READMESKILL.md - Build Zoom Meeting Sdk App
# Meeting SDK Android Guide ## Scope Android Meeting SDK integration for default UI, custom UI, auth, start/join, and in-meeting feature modules. ## Validation Snapshot - Crawled docs path includes: `get-started`, `integrate`, `start-join-mtg-webinar`, `default-ui`, `custom-ui`, `resource/error-codes`. - API reference snapshot includes class/interface/function maps from `index.html`, `annotated.html`, `classes.html`, `files.html`, and `functions*` pages. - Local package checked: `zoom-sdk-android-6.7.5.37500` (contains `mobilertc.aar`, sample apps, dynamic sample modules). ## Practical Guidance 1. Initialize and authenticate SDK. 2. Get first successful join in default UI. 3. Add feature flags/settings and error handling. 4. Move to custom UI only for required UX control. 5. Add observability for meeting status and SDK callback failures. # Android Architecture ## Layer Model - App UI layer (Activity/Fragment/Compose wrapper). - Meeting orchestration layer (init/auth/join/start state machine). - SDK facade layer (`mobilertc.aar` interfaces and controllers). - Backend signing service (short-lived signature/JWT issuance). ## Reference Flow ```text Android UI -> App Meeting Service -> Backend Signature API -> Zoom Meeting SDK ^ | | | | v v v User actions Session state store Token/role policy Meeting callbacks ``` ## Why this split - Keeps SDK secret server-side. - Prevents UI from owning auth/security logic. - Enables deterministic retry policy on join/start failures. # Android Lifecycle Workflow ## Core Sequence 1. App boot + permissions precheck (camera, mic, notifications as needed). 2. SDK initialize (`InitSDK`-style flow in Android layer). 3. Auth for SDK access (non-login/API user paths or signed flow). 4. Join/start meeting request. 5. In-meeting event handling (audio/video/chat/share/BO/recording where enabled). 6. Leave/end meeting and release/cleanup. ## Failure Domains - Initialization errors (SDK state, app config, package conflicts). - Auth/signature mismatches (expired token, role mismatch, malformed payload). - Join/start parameter mismatch (meeting number, passcode, meeting type). - Device/media state mismatch (permissions, audio route, camera availability). # Android Join/Start Pattern ## Join (attendee) 1. Backend creates short-lived SDK signature/JWT. 2. App initializes SDK and verifies init callback success. 3. App executes join with normalized meeting number + passcode. 4. App subscribes to meeting status callbacks before join call returns. ## Start (host) 1. Backend resolves host token (`ZAK`) + role-aware signature. 2. App executes start flow and validates host privilege errors explicitly. 3. App applies host-only features conditionally (recording, management controls). ## Guardrails - Do not hardcode secret in app. - Normalize meeting identifiers as strings of digits. - Treat SDK callback thread behavior as asynchronous; avoid UI blocking. # Android Reference Map ## Sources - Docs: https://developers.zoom.us/docs/meeting-sdk/android/ - API Reference: https://marketplacefront.zoom.us/sdk/meeting/android/index.html ## Crawl Coverage Snapshot - Docs pages captured: `70` - API reference pages captured: `1003` ## Key API Entry Pages - `index.md` - `annotated.md` - `classes.md` - `files.md` - `hierarchy.md` - `functions.md` and `functions_*` - `functions_func_*` - `functions_vars_*` ## Notable API Surface Areas - Meeting lifecycle and service controllers - Audio/video/share controllers - Breakout room and webinar interfaces - AI Companion / smart summary interfaces - Raw data helpers and delegates ## Drift Signals to Watch - Newly added `AI Companion`, `smart summary`, and `avatar` interfaces. - Legacy helper names retained with new parallel interfaces. # Android Meeting SDK Environment Variables | Variable | Required | Purpose | Where t