简介：Android Studio Chipmunk 2021.2.1.10 Windows 版安装包，适用于需要锁定特定 IDE 版本进行 Android 开发的工程师与学习者。作为 2021.2.1 系列构建，它常用于与 Dolphin、Bumblebee 等版本配套的工程环境，解决 Gradle 插件兼容、模拟器调试及离线安装等场景下的版本匹配问题。压缩包共包含 2000 个文件，以 jar 库文件、py 脚本、json 配置、ttf/otf 字体、webp 图标及 dll 动态库为主，同时附有 exe 启动程序、xml/layout 界面描述和 txt 说明文档，整体约 944.82MB，目录结构完整，便于离线安装或迁移至内网环境。已有 427 人学习下载。通过该资源可获得官方 Windows 发行版完整构件，包括核心 IDE 模块、构建工具链、平台组件以及各类许可证与说明文件，适合需要核对版本细节、开展兼容性测试或建立本地备份的开发者使用，能有效节省逐项下载和配置的时间。
1. 还在折腾 Chipmunk 的人，多半不是怀旧：你需要 android-studio-2021.2.1.10-windows.zip 的真正理由
当一个项目老老实实跑在 Gradle 7.4 和 AGP 7.1.3 上，而你把它拖进最新版 Android Studio，迎面而来的是一句 "Minimum supported Gradle version is 8.0" 时，你会和我一样把目光转向历史版本归档页。Android Studio Chipmunk（对应 Windows 平台这个免安装包 android-studio-2021.2.1.10-windows.zip）是 2022 年发布的 2021.2.1 系列，我把它留到现在不是因为念旧，而是它依然能干干净净地跑起一批被新 IDE 无情抛弃的老工程。它适合维护老项目、学习旧版本代码、或者所在团队把 Gradle 版本锁死的开发者；全新项目我不建议用它，但老项目上它比最新版省出的事，绝对值得你装一份。
2. 下载与安装包核对：zip 免安装版才是老版本并存的唯一正解
2.1 认准 2021.2.1.10 这个构建号，Chipmunk 内部也有差异
Chipmunk 是 Android Studio 2021.2.1 的官方代号，同一个代号下还有一堆小补丁版本，2021.2.1.10 是 Windows 平台上被用得较多、口碑相对稳定的一个构建号。你搜 Android Studio 下载时，看到的大多是当前稳定版，或者停留在 2021.2.1 大版本就以为万事大吉；实际上 2021.2.1.1、2021.2.1.10、2021.2.1.16 这些后缀修的问题各不相同，有的修了 Windows 上文件监听失效，有的修了 Gradle 同步时 JVM 崩溃。既然标题写的是 android-studio-2021.2.1.10-windows.zip，就照着这个完整构建号去找，不要只认 "Chipmunk" 四个字，更不要下成 2021.2.1 系列早期的试验版。
官方历史版本入口一般藏在 Android Studio 归档页，页面里能看到所有大版本和对应代号，往下翻到 2021.2.1 那一栏，挑 Windows 平台 zip 包下载。这里提醒一句：下载页给出的下载链接走的是 Google 的官方存储服务器，Windows 下建议用浏览器直接下载，别用多线程下载工具去抢，否则很容易出现压缩包大小一致但内部文件损坏的情况，后面编译阶段会以各种诡异报错来报复你。
2.2 zip 包和 exe 安装包的区别：多版本并存是 zip 的主场
常见的 Android Studio 安装教程都讲 exe 安装包，双击下一步、选路径、装完自动创建桌面图标。exe 版本适合只装一个 IDE 的人；但你要在老项目和新项目之间来回切版本，zip 包才是正确姿势。zip 包解压出的目录里自带 bin、plugins、lib 等完整结构，不在注册表里写东西，不抢文件关联，也不往你系统服务里塞东西。
| 对比项 | zip 包 | exe 安装包 |
|---|---|---|
| 安装方式 | 解压即用，免安装 | 向导安装，可能要求重启 |
| 多版本并存 | 随便放多个目录 | 同一机器装多个版本容易冲突 |
| 卸载 | 删目录即卸载 | 需要走卸载程序，残留风险 |
| 文件关联 | 不抢占 | 默认接管 .java/.kt 等打开方式 |
| 更新 | 手动下载新版替换 | 内置自动更新提示 |
我给老项目准备的是一台机器上同时挂着 Arctic Fox 和 Chipmunk 两个 zip 目录，互相不干扰。需要注意的细节是解压目录不要放在需要管理员权限的位置，比如 C:\Program Files，因为 Gradle、SDK、缓存目录运行时都要写文件，权限不足会触发 "Access is denied" 这类安装环节最难排查的问题。
2.3 解压前的完整性校验与目录规划
解压之前先做一步校验，这一步能过滤掉 80% 的文件损坏问题。用 PowerShell 执行哈希比对，比对对象是下载页标注的 SHA-256 值，我见过太多人跳过这一步，然后被编译期 "unexpected end of archive" 之类的问题折磨一下午。
# 校验下载文件的 SHA-256，输出值和下载页上的值要完全一致 Get-FileHash .\android-studio-2021.2.1.10-windows.zip -Algorithm SHA256 # 解压到独立开发工具目录，目录路径不要带空格和中文 Expand-Archive -Path .\android-studio-2021.2.1.10-windows.zip -DestinationPath D:\dev\ # 确认解压结果，关键看是否有 bin、plugins、lib 三个目录 Get-ChildItem D:\dev\android-studio逻辑说明：Get-FileHash 拿到的是 64 位十六进制字符串，校验不等就重新下载，这是成本最低的后悔药。Expand-Archive 在 PowerShell 5.1 以上可用，Windows 7 上需要先装 PowerShell 新版本。路径这个坑我必须单独强调：把 IDE 放在 D:\dev\android-studio 这种纯英文无空格路径是我的习惯，因为 NDK、CMake、Gradle 对带空格或中文的路径处理逻辑非常玄学，有些版本能跑，有些版本在 aapt2 环节突然翻车，报错还指向完全无关的文件。
3. 首次启动与 JDK/SDK 配置：让 Chipmunk 在 Windows 上第一次就能编译
3.1 Chipmunk 自带 JBR 11，但外部 JDK 环境会来抢优先级
Chipmunk 解压后双击 bin\studio64.exe 就能启动，它内置了 JetBrains Runtime（JBR），默认情况下 IDE 自身不需要你配置 JAVA_HOME。但这只是 IDE 能启动，不代表项目能构建。真正的问题是 Gradle 构建进程用哪个 JDK：如果你的 Windows 系统环境变量里 JAVA_HOME 指向 JDK 17 或更高，Gradle 守护进程很可能跳过 Chipmunk 内置的 JBR 11，直接拿 JDK 17 去跑编译。AGP 7.1 在 JDK 17 下能跑，但部分老插件、老的 annotationProcessor 会在 17 上罢工，报的错五花八门，比如 "Unsupported class file major version 61"。
我一般会在项目的 gradle.properties 里显式锁定 Gradle 使用的 JDK 路径，这样不管系统环境变量怎么乱，构建进程都只认 Chipmunk 自带的那份 JBR。
org.gradle.java.home=D:/dev/android-studio/jbr参数说明：org.gradle.java.home 接受的是 JDK 根目录，不是 bin 目录，也不是 JAVA_HOME 那种带引号的写法。如果这个路径配错，Gradle 会在同步阶段直接报 "Java home supplied is invalid"。Windows 路径里的反斜杠在 properties 文件里要转义或用正斜杠，所以我习惯统一用正斜杠，省得漏写转义。配好后可以在 Android Studio 的 Terminal 里执行gradlew -v，看到 JVM 那一行指向 D:/dev/android-studio/jbr 就是成功。
3.2 用 sdkmanager 把 SDK 拉到本地，避开图形界面首次启动的坑
zip 包首次启动时，会弹 SDK 路径设置界面。如果你电脑上本来就有 Android SDK，直接指过去；如果是全新环境，别急着在图形界面点下载。图形界面下载 SDK 容易遇到两个问题：一是默认下载的是最新的 build-tools 和 platform，老项目未必需要；二是下载过程中日志不透明，卡死在某个文件上时你连进度条都看不清。
我习惯直接用命令行把 SDK 装到位，再去启动 IDE。这个方案依赖 cmdline-tools 里的 sdkmanager，Windows 下是可执行的批处理文件。
# 进入 cmdline-tools 的 bin 目录，latest 是当前版本目录 cd D:/dev/android-sdk/cmdline-tools/latest/bin # 先接受所有组件许可协议，这一步不能跳过 ./sdkmanager.bat --licenses # 安装项目需要的 platform、build-tools 和 platform-tools ./sdkmanager.bat "platforms;android-31" "build-tools;30.0.3" "platform-tools"逻辑说明：--licenses会逐个列出协议并要求输入 y，在 Windows 的 cmd 里直接一路 y 回车即可。后面的包名引号不能去掉，分号是包名的组成部分。这里选 android-31 是因为 Chipmunk 时代的多数老项目 compileSdk 都在 31 左右；如果你的项目 compileSdk 是 30，就换成platforms;android-30。build-tools 30.0.3 覆盖绝大多数 AGP 7.x 老项目，如果构建报缺少其他版本，再按需补装。platform-tools 负责 adb，调试真机必须有。
3.3 中文界面与插件初始化：一次配好，后续省心
热搜里很多人问 Android Studio 怎么设置中文，Chipmunk 这一版是支持官方中文语言包的。步骤是启动 IDE 后进入 Settings -> Plugins，在 Marketplace 搜索 "Chinese" 或 "中文语言包"，找到 JetBrains 官方发布的 "Chinese (Simplified) Language Pack" 插件安装并重启。这里有一个版本匹配的坑：插件市场默认给出的是适配最新 IDE 的版本，直接点 Install 可能提示 "incompatible with this IDE"，需要在插件详情页里手动选择兼容 2021.2 系列的旧版本。装好后就变成中文界面，属性面板、菜单项、向导文本都能中文化，学习成本会低不少。
插件初始化这一步我建议一起做完：Database Inspector 是 Chipmunk 自带的数据库查看工具，不需要额外装插件，连接模拟器里的应用就能查看 Room 或 SQLite 数据；如果你想在编辑器里直接看 JSON 格式化，可以装一个 "JSON Helper" 之类的静态插件。不要贪多，这一版 IDE 插件装得越多，启动越慢，而且某些插件会用上你项目 JDK 配置，引发构建阶段的新冲突。
4. 老项目迁移到 Chipmunk：Gradle 与 AGP 的兼容矩阵和最小改动
4.1 先看 gradle-wrapper.properties，再动 build.gradle
把老项目导入 Chipmunk 后，第一步不是点 Sync，而是打开 gradle/wrapper/gradle-wrapper.properties 确认 distributionUrl 指向的 Gradle 版本。Chipmunk 内置的 AGP 测试基线偏向 7.0/7.1，对应 Gradle 版本有明确下限。常见匹配关系是 AGP 7.0 需要 Gradle 7.0 以上，AGP 7.1 需要 Gradle 7.2 以上，AGP 7.2 需要 Gradle 7.3.3 以上。很多老项目导入新 IDE 报 "Minimum supported Gradle version"，本质就是 Gradle wrapper 版本太低，而不是项目本身有问题。
| AGP 版本 | 最低 Gradle 版本 | 典型 Android Studio 版本 |
|---|---|---|
| 7.0.4 | 7.0.2 | Arctic Fox |
| 7.1.3 | 7.2 | Chipmunk |
| 7.2.2 | 7.3.3 | Chipmunk 补丁版 |
| 7.4.0 | 7.5 | Dolphin |
我处理过的典型 Chipmunk 迁移项目，AGP 7.1.3 配合 Gradle 7.4 是少折腾的组合。gradle-wrapper.properties 里 distributionUrl 需要指向官方发行版地址，Windows 下注意 URL 里的冒号要转义。
distributionBase=GRADLE_USER_HOME distributionPath=wrapper/dists distributionUrl=https\://services.gradle.org/distributions/gradle-7.4-bin.zip zipStoreBase=GRADLE_USER_HOME zipStorePath=wrapper/dists参数说明：-bin后缀是基础发行包，比-all包小一半；想要看 Gradle 源码调试构建脚本时才用-all。改完 wrapper 后，在项目根目录执行gradlew.bat ideasync或直接在 IDE 里重新同步。bin 包没有源码，所以你断点调试 Gradle 插件内部逻辑时会看不到源码，这是正常的，不是依赖没下全。
项目级 build.gradle 里 AGP 依赖也要对应调整，常见写法是保留 google() 和 mavenCentral() 两个仓库，classpath 指定为 7.1.3：
buildscript { repositories { google() mavenCentral() } dependencies { classpath "com.android.tools.build:gradle:7.1.3" } }逻辑说明：AGP 版本号必须和 Gradle wrapper 匹配，否则同步直接红。classpath 里的 AGP 版本也不是越高越好，Chipmunk 上跑 AGP 7.4 虽然可行，但老项目里常见的一些自定义 Gradle Task 可能在 7.4 的 API 变更下失效，所以只升到 7.1.x 是最稳的。
4.2 资源重复错误与自定义组件失效：迁移高频两个坑
热搜里 "android studio 资源重复错误" 在 Chipmunk 迁移场景太常见了。现象是编译报 "Android resource linking failed"，指向某个 res 文件说重复资源。原因大多是历史项目里 res 目录存在同名文件，或旧 IDE 自动生成的 values 文件被复制多份，还有一部分是迁移时把整个项目目录复制来复制去，复制出了残留的 values-xx 目录。解决方式不是删文件碰运气，而是先在 IDE 左下角找到 Resource Manager，按资源名搜索定位重复项；确认后删掉多余文件，再 Build -> Clean Project。如果报错信息模糊，直接去 build/intermediates/incremental 目录下看合并后的资源文件，那个目录会显示合并产物里哪个文件声明了重复名称。
另一个迁移高频问题是自定义组件在布局编辑器里显示不出来，编译却能过。现象是布局预览区域里自定义 View 整块空白，或者显示成灰色矩形。原因是 Chipmunk 的布局渲染器需要完整依赖树才能实例化自定义组件，老项目如果之前靠旧 IDE 的隐式依赖才能渲染，换到 Chipmunk 后那些默认依赖就没了。解决思路是检查 app/build.gradle 里是否显式声明了相关支持库，比如自定义 View 继承自 AppCompat 的组件，就要有 androidx.appcompat 依赖；如果项目用的是老 support 包，AGP 7.x 已经默认不编入 support 库，迁移时统一换到 androidx 版本更省事。
4.3 迁移后的三个必调设置：namespace、JVM 内存、编码
老项目迁到 Chipmunk 上，除了 Gradle 和 AGP，还有三个设置我每次都会顺手调整。
第一个是 module 的 namespace。AGP 7.0 开始强制 namespace 独立声明，老项目里 applicationId 和包名混在一起的情况需要拆开。在模块的 build.gradle 里加上namespace 'com.example.app'，如果漏了，同步会报 "Namespace not specified"。
第二个是 gradle.properties 里的 JVM 内存。Chipmunk 默认的 gradle 守护进程内存偏保守，Windows 上老项目编译频繁 OutOfMemory 时，首先看这里。
org.gradle.jvmargs=-Xmx2048m -Dfile.encoding=UTF-8 android.useAndroidX=true android.enableJetifier=true参数说明：-Xmx2048m是给 Gradle 守护进程的最大堆内存，项目模块多就调到 3072m 或 4096m，但注意别超过本机物理内存的一半，否则 IDE 和 Gradle 会互相争抢内存，整机卡死。-Dfile.encoding=UTF-8是防止 Windows 默认 GBK 编码导致的中文资源乱码和编译告警，这个参数在老项目的 Windows 环境下几乎必备。android.useAndroidX和android.enableJetifier是把旧 support 库自动迁移到 androidx 的开关，老项目迁移时通常要打开；如果项目已经纯 androidx，Jetifier 可以关掉以加快构建。
第三个是 Settings -> Build Tools -> Gradle 里的 "Use Gradle from" 选项，默认可能是 wrapper，确认它指向 gradle-wrapper.properties 里声明的版本；下拉列表选 "Specified location" 时，路径必须真实存在，否则同步奇怪报错。
5. Chipmunk 常见问题排查：安装、编译、打包三个环节的踩坑记录
5.1 安装环节：双击没反应、JVM 找不到、解压被安全软件拦截
现象一：解压完成后双击 studio64.exe，屏幕闪一下就没下文了。原因一般是 JDK 或 JBR 路径不对，或者压缩包在解压时文件不完整。解决思路是先打开 bin 目录下的 studio64.exe.vmoptions 文件，看里面是不是配了不合法的启动参数；没有头绪就到命令行手动执行D:\dev\android-studio\bin\studio64.exe，Windows 下用 cmd 运行能看到与图形启动不同的错误输出。还有一个容易忽略的点是图形界面启动可能被 UAC 拦截，右键以管理员身份运行一次，如果裸启动正常而管理员启动失败，多半是 vmoptions 里配了某个受限路径。
现象二：启动时提示 "No JVM installation found" 或者 "Unable to detect Java SDK"。原因是系统环境变量里的 JAVA_HOME 被改成无效路径，或者 IDE 的 JBR 目录被安全软件清理。解决方式是查看D:\dev\android-studio\jbr目录是否存在且完整；不存在就重新解压 zip 包；存在则手动在环境变量里补一个有效的 JAVA_HOME，指到 jbr 目录即可。
现象三：解压过程中报 "无法创建目录" 或中途报错。原因多半是杀毒软件实时防护在拦截，zip 包里的 jbr 目录含有较多可执行文件，某些主动防御引擎会执行启发式扫描，把正在释放的文件判定为风险。解决方式是先把目标目录加入杀毒软件白名单，然后重新解压；同时用第 2 章的哈希校验确认原始压缩包没坏，避免把网络中断导致的损坏包误判成杀毒问题。
5.2 编译环节：Gradle 下载慢、SDK 缺失、AAPT2 崩溃
现象一：首次 Sync 卡在 "Downloading Gradle-7.4-bin.zip" 长时间不动。原因是 Gradle 发行包下载依赖公网，Windows 上如果网络状况不佳会非常煎熬。解决方式有两个：一是用下载工具把 gradle-7.4-bin.zip 提前拿到，放到C:\Users\<用户名>\.gradle\wrapper\dists\gradle-7.4-bin\<哈希>\目录下，Gradle 检测到本地有同名文件就不会重新下载；二是在项目 gradle-wrapper.properties 里临时换一个可访问的镜像地址，这个方案我一般只在紧急时用，因为镜像同步版本有延迟，而且安全性和完整性需要额外校验。
现象二：Sync 报 "SDK location not found" 或者 "Failed to find target android-xx"。原因是 IDE 里配置的 SDK 目录没有对应 platform 包。解决方式是到 Settings -> System Settings -> Android SDK 查看 SDK 路径，然后用第 3 章的 sdkmanager 命令补装指定版本。这里要注意 platforms 包名里的版本号必须和项目 compileSdk 完全一致，比如 compileSdk 31 对应platforms;android-31，装了 32 不会自动兼容 31。
现象三：编译过程中 AAPT2 崩溃，报 "Daemon is not compatible with this JVM" 或直接返回非零退出码。原因通常是 AAPT2 守护进程在 Windows 上被安全软件干扰，或 JVM 参数给得不合理。解决方式是先在 gradle.properties 里把 org.gradle.jvmargs 调回常见配置，再执行gradlew --stop停掉所有守护进程后重试；还不行就关掉 AS 的 "AAPT2 from Maven" 选项，让 IDE 使用 SDK 自带的 aapt2，路径在 build-tools 目录里。
5.3 打包环节：构建目录消失、签名信息被跳过、自定义打包任务失效
现象一：执行 assembleRelease 后发现 build/outputs/apk 目录下没有产物，日志里也没有明显错误。原因是多渠道或者变体维度导致 APK 输出在变体子目录下，比如build/outputs/apk/release/和build/outputs/apk/demo/release/是两回事。解决方式是打开 IDE 右侧 Gradle 面板，找到 app -> Tasks -> build，展开对应变体看 assembleRelease 实际归属哪个任务组；日志里搜 "APK" 关键字，输出的绝对路径才是产物真实位置。
现象二：打包成功但 APK 没有签名，安装到真机报 "App not installed"。原因是构建类型里没有配置签名，Gradle 只生成了未签名的 release 包。解决方式是在 app/build.gradle 里补充 signingConfig，或临时在android.buildTypes.release中把signingConfig指到 debug 的签名配置。不要把签名密码直接写进 build.gradle 提交到 Git，我习惯用keystore.properties文件配合storeFile相对路径加载，这个文件不进版本库。
现象三：迁移前项目里的自定义 Gradle Task 在 Chipmunk 上执行报 "Could not get unknown property 'variant'"。原因是 AGP 7.x 把 variant API 改成了不稳定的新接口，很多旧版 Task 直接用android.applicationVariants遍历，在 7.0 以上默认不可用。解决方式是给项目的build.gradle里加回旧接口的兼容开关，但不要长期依赖，换到新 variant API 才是正路。
6. 再往前一步：用命令行把 Chipmunk 变成可脚本化的构建工具
zip 包最大的隐藏价值是命令行可以完全接管它。平时双击 studio64.exe 打开 IDE，是把它当编辑器用；实际上 bin 目录下的 studio64.exe 支持一堆启动参数，配合项目里的 gradlew，完全可以做到不打开 IDE 就完成同步、编译、打包的全流程。我自己的习惯是把老项目的日常构建都扔给命令行，IDE 只用来写代码和看布局，这能明显减少构建时 IDE 被冻住的时间。
# 命令行直接启动 Chipmunk，指定配置目录和 JVM 编码 D:/dev/android-studio/bin/studio64.exe -Dfile.encoding=UTF-8 # 不打开 IDE，直接编译 Debug 包，输出完整异常栈 cd D:/work/legacy-project ./gradlew assembleDebug --stacktrace --console=plain参数说明：-Dfile.encoding=UTF-8是给 IDE 进程的 JVM 参数，解决 Windows 中文环境下的编码乱码问题，这个参数在 IDE 工具栏的 Help -> Edit Custom VM Options 里也能等效配置。--console=plain是让 Gradle 输出环境友好的纯文本日志，配合--stacktrace排查问题比在 IDE 里看 Build 窗口明确得多。如果命令行构建报 "Unable to start the daemon process"，直接执行./gradlew --stop杀掉所有旧守护进程，再重新构建，这个操作在我的日常排障里占了三分之一。
还有一个值得养成的习惯是给 SDK 和 IDE 做一个初始化脚本，把第 3 章的 sdkmanager 安装命令和第 4 章的 gradle.properties 配置写成一个可重复执行的批处理文件。我在这上面吃过亏：有一回把整个 D:\dev\android-sdk 目录复制到新电脑，以为一劳永逸，结果新机器上老项目打包时才发现缺了 build-tools 30.0.3，而 sdkmanager 又不会自动补装旧版本，白白浪费了两个小时。从那以后，我每个开发环境都留一份 init_sdk.bat，内容就是那几条 sdkmanager 命令加一个 gradle.properties 模板。老项目换个机器，跑一遍脚本，再打开 Chipmunk，基本不会再栽在环境问题里。如果你手头正好在维护老项目，Zip 包加命令行这条路径值得提前铺好，希望帮到你。
本文还有配套的精品资源，点击获取
