先找准原因，再改代码
错误提示是线索，却不一定是根因。我们会检查相关构建版本、触发步骤、日志和近期改动。
例如，“上传失败”可能源于登录过期、网络中断、服务端返回了应用未处理的响应，或生命周期问题。各自需要不同修法。这只是说明排查过程的例子，不是客户案例。
原因尚不明确时，先进行范围有限的调查，比没看项目就承诺维修价格和日期更负责。
可以调查哪些问题？
崩溃与异常行为
复现故障，找到受影响的代码路径，并检查修复是否解决原问题、有没有在相邻功能引入新问题。
构建与依赖故障
调查无法编译的项目、冲突的依赖，或正式版与开发版行为不同的问题。必要的版本变更要记录清楚，不能藏在无关升级中。
Android 兼容问题
检查受平台更新、权限规则或特定设备行为影响的功能。应明确支持哪些 Android 版本和设备，而不是笼统承诺“全部支持”。
卡顿或不稳定的页面
分析加载、滚动或用户操作时实际执行的任务。提出优化前，应先建立合适的性能基准。
未完成的功能与接手项目
分清已完成、缺失以及被外部依赖阻碍的部分。有时继续开发之前，先形成一份清晰的恢复计划更有价值。
排查需要哪些资料？
初次留言请说明看到了什么、预期应该怎样，以及复现步骤。还请注明应用技术、受影响设备，以及问题出现在调试版还是正式版。
要实现并长期维护代码级修复，通常需要源码访问。APK、截图或崩溃报告有助于初步判断，但不能代替获授权的源码项目。
请勿在咨询中加入密码、API 密钥、签名材料或未经处理的客户数据。后续可以安排安全访问与脱敏诊断资料。
修复应有验证依据
项目范围应明确故障场景，以及修改后需要重复执行的检查。视具体问题，交付物可能包括源码差异、复现说明、相关测试和测试安装包。
设备特有问题要记录验证用的型号、Android 版本和构建版本。后端问题则需区分应用端修复与移动开发者无法单独完成的服务端改动。
一项错误在一次测试中消失，不代表应用中所有无关问题也已解决。
持续维护 Android 应用
维护范围可以包括约定的兼容工作、依赖更新、定期缺陷分流和发布支持。协议应写明覆盖哪个代码库、所需权限以及请求优先级。
新功能、大规模重设计和紧急响应需要分别议定。一般维护咨询不应被理解为全天候服务承诺。
若要计划原生功能升级，请看 Kotlin 与 Jetpack Compose 开发；现有跨平台项目可查看 Flutter 应用开发。
支持应用项目，不代替第三方服务的管理者
本服务面向你拥有或有权维护的软件项目，并不承诺修改无关的商业应用、恢复他人账户访问，或绕过第三方平台管控。
个人 Android 设备问题，请转至 设备支持服务。
常见问题
能接手其他开发者编写的应用吗？
可以，前提是你拥有必要权利和访问权限。估算实施工作前，我们会检查项目及其构建说明。
没看代码前能保证修好吗？
不能。有些问题依赖缺失的源码、外部服务或硬件限制。初步评估会明确可调查的范围及仍需取得的权限。
应用已经无法构建，还能帮忙吗？
可以。恢复构建可作为第一阶段；重新得到开发测试版与准备正式发布版，可能需要不同的检查。
应用商店提交遇到问题也能处理吗？
我们可以评估范围内的技术问题，例如构建配置或应用行为。商店的账户决定与最终审核结果不由开发者控制。
会把整款应用重写吗？
不会预设如此。定点修复或分阶段改进可能更合适。重写应由证据与双方认可的产品决定来支持。
修复后还提供维护吗？
可另行约定维护服务，并在开始前写明覆盖范围、请求处理和排除事项。
告诉我们：应该发生什么，实际又发生了什么
提供操作步骤、受影响平台，以及是否能访问源码项目，就足以开始讨论。