移动开发应用安全密码学认证鉴权【免费下载链接】androidBitwarden mobile apps (Password Manager and Authenticator) for Android.项目地址https://gitcode.com/gh_mirrors/and/android点击查看免费下载本篇技术指南围绕 Bitwarden Android 仓库中的 .claude/commands/work-on-android.md 命令展开系统讲解其定义的「实现 → 测试 → 构建验证 → 自查 → 提交 → 评审 → 拉取请求」七阶段开发工作流。文章将逐一拆解每个阶段的执行要点、出口门禁与所依赖的仓库级技能与工具链含构建命令、测试基类、静态分析配置并结合 .claude/skills 下的源码级实现模式与 app/build.gradle.kts、detekt-config.yml 等真实配置让你能够基于该工作流独立驱动一次 Bitwarden Android 功能的完整开发闭环并掌握其背后可复用的工程规范。文档定位一条面向 AI 协作者的 Android 全生命周期流水线work-on-android.md是 Claude Code 的 command 定义文件通过/work-on-android task触发其中task可以是任务描述、开发计划或 Jira ticket 引用例如PM-12345。它不再局限于「写一段代码」而是将一次开发任务拆解为 7 个串行阶段要求 AI 助手每个阶段调用仓库中预置的专用 Skill技能来完成具体工作每个阶段完成后向用户汇报结果并在用户明确确认后才进入下一阶段阶段失败时测试不过、lint 报错等在当前阶段内循环修复绝不带着失败结果向下游推进支持用户跳过不适用的阶段也支持从「已完成一部分」的任务中间切入。这与 .claude/CLAUDE.md 中描述的完整协作链路是配套的先用/plan-android-work task做需求收敛与实现规划再用/work-on-android task走实现闭环最后用/review-android PR#做结果评审。换言之本命令是整条链路中「执行落地」的引擎。七阶段总览阶段核心动作依赖技能 / 命令出口门禁必须向用户确认Phase 1 实现理解任务、探索代码、编写实现Skill(implementing-android-code)汇总实现内容确认进入测试Phase 2 测试为 Phase 1 变更编写测试Skill(testing-android-code)汇总测试内容确认进入构建验证Phase 3 构建与验证运行测试、lint、detektSkill(build-test-verify)汇报构建/测试/lint 结果确认进入自查Phase 4 自查质量门禁检查bitwarden-delivery-tools:perform-preflight分享自查结果确认准备提交Phase 5 提交暂存并以规范格式提交bitwarden-delivery-tools:committing-changes确认提交成功询问是否继续评审/建 PRPhase 6 评审对已提交 diff 做本地代码评审/bitwarden-code-review:code-review-local需插件分享评审发现确认进入 PR 创建Phase 7 拉取请求创建规范描述的 PRbitwarden-delivery-tools:creating-pull-request默认创建Draft PR下文按阶段逐一深入。Phase 1 实现以仓库模式驱动的代码编写本阶段要求调用Skill(implementing-android-code)引导实现。该技能定义在 .claude/skills/implementing-android-code/SKILL.md其核心是总结 Bitwarden 代码库特有的关键模式与反模式避免 AI 写出「形似而神不似」的代码。从仓库看几个高频模式构成了实现的骨架State-Action-EventSAEViewModel 模式。所有 ViewModel 通过BaseViewModelState, Event, Action强制单向数据流实现类位于 ui/src/main/kotlin/com/bitwarden/ui/platform/base/BaseViewModel.kt。技能文档强调的关键约束包括用HiltViewModel标注State 必须是Parcelize data class : ParcelablehandleAction(action: A)必须是同步分发协程内不得直接改mutableStateFlow而应通过sendAction()投递内部 Action 回到同步处理器中更新状态通过SavedStateHandle[KEY_STATE]做进程死亡恢复敏感数据必须标注IgnoredOnParcel以防泄密。类型安全导航。导航全部基于 kotlinx.serialization 的类型安全路由Serializable路由数据类 ...Args抽取辅助类 NavGraphBuilder.{screen}Destination()扩展 NavController.navigateTo{Screen}()扩展完整模板见 implementing-android-code/templates.md。仓库中还提供了大量真实的实现范本可供对照例如 app/src/main/kotlin/com/x8bit/bitwarden/ui/auth/feature/login/LoginViewModel.kt。完整的架构决策与代码风格规则见 docs/ARCHITECTURE.md 与 docs/STYLE_AND_BEST_PRACTICES.md。Phase 2 测试遵循仓库既定测试范式本阶段调用Skill(testing-android-code)编写测试。该技能定义在 .claude/skills/testing-android-code/SKILL.md测试技术栈为JUnit 5jupiter MockK Turbine kotlinx.coroutines.test Robolectric Compose Test且约定测试统一在 en-US locale 下运行以保一致性。两个基类是测试的入口ViewModel 测试一律继承 ui/src/testFixtures/kotlin/com/bitwarden/ui/platform/base/BaseViewModelTest.kt它自动注册MainDispatcherExtensionUnconfinedTestDispatcher并提供stateEventFlow()辅助函数用于同时断言 StateFlow 与 EventFlow。典型模式为mockk()依赖 →coEvery { }桩定挂起函数 → 用 Turbine 的awaitItem()依次断言「初始状态 → 触发 Action → 新状态」最后coVerify校验调用。Compose 界面测试则继承BitwardenComposeTest位于 app 模块它预配置了 FeatureFlags、AuthTab、Biometrics 等全部 Bitwarden 管理器并注入固定Clock保证时间相关测试可确定。测试范式文档还明确区分了两类 Flow 的断言策略详见 flow-testing-patterns.mdFlow 类型是否重放首个断言动作StateFlow重放最近值1 个先awaitItem()拿到当前状态EventFlow不重放先expectNoEvents()再触发仓库中的大型测试文件如 app/src/test/kotlin/com/x8bit/bitwarden/MainViewModelTest.kt超过 1400 行就是这一范式的规模级实践样本。Phase 3 构建与验证测试、lint 与 detekt 全绿才能放行本阶段调用Skill(build-test-verify)见 .claude/skills/build-test-verify/SKILL.md执行构建与质量验证。该技能文档沉淀了多条对 Bitwarden 仓库至关重要的实操经验构建命令基于仓库的 settings.gradle.kts 多模块结构与 app/build.gradle.kts 变体配置# Debug 构建app 模块为密码管理器authenticator 模块为 2FA 验证器 ./gradlew app:assembleDebug ./gradlew authenticator:assembleDebug # Release 构建需要签名密钥 ./gradlew app:assembleStandardRelease ./gradlew app:bundleStandardRelease # F-Droid 构建不含 Google 服务 ./gradlew app:assembleFdroidRelease测试命令的关键坑app 模块默认 flavor 是standard因此必须使用app:testStandardDebugUnitTest而非testDebugUnitTest。同时建议用 grep 过滤器在首轮就抓取失败明细./gradlew app:testStandardDebugUnitTest 21 | grep -E FAILED|BUILD|expected:|actual:|AssertionError|failures | head -30 # 只跑单个测试类 ./gradlew app:testStandardDebugUnitTest --tests com.x8bit.bitwarden.SomeTest 21 | grep -E FAILED|BUILD|expected:|actual:|AssertionError|failures | head -30 # 全模块单元测试 ./gradlew test静态分析项目对 detekt 配置了-Pprecommittrue开关可将扫描范围限制为已暂存文件与仓库 pre-commit 钩子同机制避免全量扫描拖慢开发节奏。仓库根目录的 detekt-config.yml 给出了质量红线例如maxIssues: 0零告警才放行、MaxLineLength: 120、格式化规则组autoCorrect: true、UndocumentedPublicFunction强制公开函数必须有 KDoc以及CyclomaticComplexMethod阈值 15、LongMethod阈值 60等复杂度约束。Android Lint 与完整验证套件可分别通过./gradlew lint与./fastlane check执行。失败即循环本阶段出现任何失败测试、lint、detekt都必须修复后重新验证直到全绿才允许进入下一阶段。Phase 4 自查提交前的质量门禁Phase 4 调用bitwarden-delivery-tools:perform-preflight做提交前质量门禁检查对所有变更进行一遍系统性审阅并修复发现的问题。该技能由 Bitwarden 的 delivery-tools 插件提供属于外部插件能力需要在环境中安装对应插件方可调用。仓库内部同时提供了与自查强相关的本地资源.claude/skills/reviewing-changes 下按变更类型划分了可勾选的评审清单——bug-fix.md、feature-addition.md、dependency-update.md、refactoring.md、ui-refinement.md 与 infrastructure.md并配套 reference/architectural-patterns.md、security-patterns.md、testing-patterns.md 等评审准则可作为 preflight 执行时的对照依据。Phase 5 提交规范化的 commit 信息Phase 5 调用bitwarden-delivery-tools:committing-changes将变更暂存并提交要求使用规范格式的提交信息。门禁要点是提交成功后向用户确认是否继续进入评审与 PR 创建或就此结束。也就是说提交点也是工作流的「可停靠站」便于用户在进入公开变更前对增量代码做人工复核。Phase 6 评审对已提交 diff 的本地代码评审Phase 6 有明确的前置条件必须已安装 Bitwarden Plugin Marketplace 提供的bitwarden-code-review插件否则应提示用户安装或跳过本阶段。满足前置后启动子代理执行/bitwarden-code-review:code-review-local对已提交的 diff做本地代码评审local 模式不涉及远端 PR并对发现的问题进行验证与修复。仓库内 .claude/prompts/review-code.md 与 .claude/skills/reviewing-changes/SKILL.md 提供了评审方法论与示例输出见 examples/review-outputs.md可辅助理解评审结论的产出形态。Phase 7 拉取请求默认 Draft等待显式放行最终阶段提示用户调用bitwarden-delivery-tools:creating-pull-request生成带规范描述与格式的 PR。默认以Draft PR形式创建除非用户明确要求 ready-for-review 的 PR——这一默认策略保证变更在合流前仍有充分的评审与调整窗口是团队协作节奏上的刻意设计。协作守则AI 与人的阶段契约命令末尾的 Guidelines 定义了 AI 助手在整个流程中的行为边界同样是工作流可落地的关键始终显式声明当前所处阶段避免用户迷失在长流程中未经用户确认绝不进入下一阶段——每个阶段的出口都是「汇报 征求确认」用户要求跳过某阶段时确认后直接进入下一个适用阶段从部分完成的任务切入时例如代码已存在直接跳到对应阶段不做重复劳动。工作流背后的工程底座要让这套七阶段流程真正跑通还需了解仓库的构建底座。从 settings.gradle.kts 可见仓库由:annotation、:app、:authenticator、:authenticatorbridge、:core、:cxf、:data、:network、:testharness、:ui十个模块组成Bitwarden SDK 从 GitHub Packages需GITHUB_TOKEN在user.properties或环境变量中配置解析并支持localSdktrue时切换到 mavenLocal 本地 SDK。app/build.gradle.kts则定义了standard/fdroid两个 flavor 与debug/beta/release三种 build typestandard面向 Google Playfdroid剥离 Google 服务debug追加.dev包名后缀并开启调试菜单beta/release开启 minify 与资源收缩。版本号按YEAR.MONTH.PATCH模式维护在 gradle/libs.versions.toml。这些参数决定了 Phase 3 中每条构建/测试命令的正确变体写法是工作流在仓库中可复现的前提。总结而言/work-on-android的价值不在于给出单点技巧而在于把一次 Bitwarden Android 开发任务组织成「实现有范式、测试有基类、验证有红线、提交有规范、评审有插件、PR 默认 Draft」的完整闭环并始终把阶段决策权交还给人。读者在接手 Bitwarden Android 开发时可直接以此为操作手册逐阶段执行。赞分享移动开发应用安全密码学认证鉴权【免费下载链接】androidBitwarden mobile apps (Password Manager and Authenticator) for Android.项目地址https://gitcode.com/gh_mirrors/and/android点击查看免费下载相关推荐Bitwarden Android 实现规划工作流从需求到分阶段落地的架构设计与实施指南Bitwarden Android 实现规划工作流从需求到分阶段落地的架构设计与实施指南 本文以 Bitwarden Android 仓库中 Claude S移动开发应用安全密码学认证鉴权Electric Agents 实体设计实战五阶段工作流与七种协调模式的完整实现指南Electric Agents 实体设计实战五阶段工作流与七种协调模式的完整实现指南 导读 本文以 designing entities SKILL htt后端数据同步数据库人工智能AI AgentMCP 服务Quarkdown 贡献指南从 Issue 到 PR 的完整开发协作流程Quarkdown 贡献指南从 Issue 到 PR 的完整开发协作流程 Quarkdown 是基于 Markdown 的排版系统可将 .qd 源文件编译为人工智能大模型预训练微调LoRARLHF强化学习分布式训练模型推理服务推理引擎模型量化模型压缩本地部署NLP上一篇gh_mirrors/aw/awesome-obsidian项目主题设计资源包图标与背景下一篇如何用GeoDa进行空间自相关分析5分钟掌握Morans I指数计算创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考