如果你在 Android Studio 的 Build 窗口里看到这么一行报错——failed to load include path C:\Users\你的用户名\AppData\Local\Android\Sdk\platforms\android-35\android.jar——大概率不是你代码写错了而是 Gradle 在编译的第一步就找不到对应 API Level 的 android.jar。我第一次遇到这个问题时差点把整个项目重新 clone 了一遍后来才发现真正原因就是 Android SDK Platform 35 没装。而这个报错最坑的地方在于它不会明说“请安装 Platform 35”只会丢给你一个“include path 加载失败”看起来像是工程配置坏了实际却不是。这篇文章我会把这个报错从出现场景、根因拆解、解决手段到防坑习惯完整过一遍覆盖 Android Studio 图形界面、命令行 Gradle 和 CI 构建三种场景。适合刚拿到别人项目的新手也适合被这个问题反复折腾的老开发。只要跟着章节走完基本能一次性解决。1. 报错现场还原它究竟在哪个环节冒出来1.1 三种高频出现场景这个报错不是只在一个地方出现。我整理了一下自己踩坑和帮别人排查的经验基本集中在三种场景里场景一打开同事发给你的项目。你本地没有这个项目clone 下来之后 Android Studio 自动开始 Gradle SyncSync 可能都显示成功了但一跑 Build 就报这个错。这种场景里问题通常出在同事的compileSdk用的是 35而你本地 SDK 里根本没有platforms\android-35这个目录。场景二手动升级了 compileSdk 版本。原来项目是compileSdk 34你想用新 API就把app/build.gradle里的版本改成了 35。改完点 Sync结果 Build 阶段立刻报错。原因很简单只改了数字没让 SDK Manager 把 Platform 35 下载到本地。场景三命令行直接跑gradlew.bat assembleDebug。这种最常见于习惯用终端构建的人。Android Studio 在 Sync 的时候有自动补装 SDK 组件的能力但命令行默认不会做这件事。你如果在命令行环境里直接构建而本地没有对应 Platform报错就会非常干脆。1.2 报错信息的真实含义要理解这个报错先要明白android.jar是干什么的。Android 应用编译的时候你的代码会引用android.app.Activity、android.os.Bundle这些系统类。这些类不是随便从网上拉的而是由 SDK 里对应版本的android.jar提供的。Gradle 在编译期会把android.jar加到编译类路径里作用相当于 JDK 里的rt.jar。所以你看报错信息里的include path指的就是编译时要引入的系统库路径。当你的compileSdk被设置为 35Android Gradle Plugin 就会去 SDK 目录下寻找platforms\android-35\android.jar。找不到就报failed to load include path。说白了这不是语法错误也不是依赖冲突就是一个简单的“文件不存在”问题。1.3 哪些人更容易踩中这个坑我总结了一下遇到这个问题的人通常有以下特征刚装好 Android Studio 不久SDK 里只有默认自带的几个 Platform比如android-34或者android-33。电脑上有多个 Android SDK 目录环境变量ANDROID_HOME指向的是旧目录。备份系统或者重装系统之后SDK 是从旧硬盘直接拷过来的目录不完整。项目是别人维护的compileSdk版本高于你本地所有 Platform。2. 根源拆解SDK 明明在为什么就是找不到 android.jar2.1 compileSdk35Platform 35 却没安装很多人对 SDK 的组成有误解以为装了 Android Studio 就等于装了所有版本。实际上Android Studio 安装包只附带一个默认的 SDK Platform。你新建项目时如果选了某个 API Level它可能帮你补装但如果是别人建好的项目直接拷过来就不会自动补。SDK Manager 里的组件分得很细Platforms目录下只有一个版本对应一个android-XX文件夹Build-Tools是独立的一套Sources for Android XX又是另外一套。你需要的android.jar只存在于Platforms目录下对应的文件夹里。只装了 Build-Tools或者只装了 Sources都没用android.jar不会自己出现。2.2 local.properties 里的 sdk.dir 指错了位置local.properties是 Android Studio 在项目根目录自动生成的一个文件里面记录着本地 SDK 路径关键字段是sdk.dir。这个文件不纳入版本管理每个开发者机器上都不一样。问题来了如果你的 SDK 实际上装在D:\Android\Sdk但local.properties里写的却是C:\Users\xxx\AppData\Local\Android\Sdk那 Gradle 去找D:\Android\Sdk\platforms\android-35时当然找不到。报错信息里的路径可能不是真实存在的路径而是配置里写错的那个路径。我见过最夸张的一个例子是从 Mac 上拷过来的项目local.properties里还是/Users/xxx/Library/Android/sdk这种 Unix 格式路径。拿到 Windows 上当然一跑一个准。2.3 环境变量把 Gradle 带偏了ANDROID_HOME和ANDROID_SDK_ROOT这两个环境变量在 Android 开发里是老演员了。很多教程让你安装完 SDK 后去系统环境变量里配置ANDROID_HOME本意是方便命令行使用。但问题在于环境变量指向的 SDK 目录和 Android Studio 里配置的 SDK 目录可能是两个地方。Gradle 在解析 SDK 路径时local.properties里的sdk.dir优先级最高如果这个文件不存在或者没写才会去看环境变量。有些老项目压根没生成local.properties那 Gradle 就会跟着ANDROID_HOME走。一旦ANDROID_HOME指向一个残缺的 SDK报错就会出现。2.4 SDK 目录迁移和精简留下的后遗症还有一类人电脑磁盘不够用发现platforms目录下全是“用不上”的旧版本就手动删掉了几个文件夹比如删了android-31、android-32觉得反正没在用。结果下一个项目就要求compileSdk 32立刻就报错。另外从别人那里拷贝的 SDK 也存在这种问题。网上下载的“绿色版 SDK”经常是精简过的可能只有最新一个 Platform。这种 SDK 平时用着还行一旦遇到版本跨度大的项目就非常容易出问题。不要问我是怎么知道的我在一台测试机上吃过同样的亏。3. 解法 A把 android-35 Platform 装全图形界面和命令行都来一遍3.1 Android Studio SDK Manager 图形安装这是最省心、也最不容易出错的方法。打开 Android Studio按顺序走一遍点击菜单栏Tools选择SDK Manager。在弹出的窗口里切到SDK Platforms标签页。在列表里找到Android SDK Platform 35勾选上。点击右下角Apply等待下载完成。完成后点OK关闭窗口。这里有个细节列表里有好几项都带“35”比如Android SDK Platform 35、Sources for Android 35、Google APIs等。你要勾选的是Android SDK Platform 35没有这个基础包装其他组件都没意义。Google APIs一般不用单独勾除非项目明确用到。安装完成后去 SDK 目录下检查一下platforms\android-35\android.jar是否存在。如果存在回到 Android Studio 重新 Sync 一次再 Build这个问题基本就消失了。3.2 命令行 sdkmanager 精确安装如果你习惯用终端构建或者在 Android Studio 的 SDK Manager 里因为网络问题下载失败可以改用命令行工具sdkmanager。先找到sdkmanager的位置。Windows 上一般在你的SDK目录\cmdline-tools\latest\bin\sdkmanager.bat如果你安装了最新版 Android Studiocmdline-tools通常都已经存在。打开终端进入这个目录执行sdkmanager.bat platforms;android-35如果你用的是 macOS 或 Linux命令是sdkmanager platforms;android-35执行过程中如果提示需要接受 license先运行sdkmanager.bat --licenses然后一路输入y接受全部协议。这一步一定要做因为很多自动安装失败的原因就是 license 没接受Gradle 的自动补装机制在这种情况下会静默放弃。装完之后可以用下面的命令确认sdkmanager.bat --list_installed或者在 Windows 终端里用dir检查dir 你的SDK目录\platforms\android-35\android.jar能看到文件就说明装好了。3.3 安装后的验证与 Gradle 缓存刷新很多时候装完 Platform回到 Android Studio 直接 Build 还是报错。别急着怀疑解法不对大概率是 Gradle daemon 还在用旧的编译环境。我自己的操作顺序是关闭 Android Studio。在终端执行gradlew.bat --stop把 Gradle daemon 停掉。重新打开 Android Studio执行File Invalidate Caches / Restart。等待索引重建再 Build。这一套下来90% 的“装完了还报错”都能解决。Gradle daemon 有时候会缓存旧的 SDK 路径信息你不主动停掉它它就一直按老记忆办事。4. 解法 B路径和配置问题的逐个修正4.1 修正 local.properties 里的 sdk.dir如果你已经确认platforms\android-35\android.jar在某个真实的 SDK 目录下存在但 Android Studio 还是报错指向另一个路径那就必须检查local.properties了。打开项目根目录找到local.properties看sdk.dir的值是不是你实际 SDK 的路径。Windows 上的写法要格外注意转义正确的例子是sdk.dirC\:\\Users\\你的用户名\\AppData\\Local\\Android\\Sdk这里反斜杠前面都加了转义符。如果你嫌麻烦也可以把路径里的反斜杠改成正斜杠Gradle 是认正斜杠的sdk.dirC:/Users/你的用户名/AppData/Local/Android/Sdk如果你的项目没有local.properties那就手动新建一个把上面这一行填进去。这里要劝一句local.properties是本地环境配置不要提交到 Git。每次在新机器上 clone 项目之后自己检查一下这个文件是个好习惯。4.2 理清环境变量的优先级环境变量和local.properties之争是这一类报错的深层原因。Android Gradle Plugin 解析 SDK 路径的顺序大致是local.properties里的sdk.dir最优先其次是ANDROID_HOME最后是ANDROID_SDK_ROOT。所以我建议你做一次完整排查在 Windows 终端里执行echo %ANDROID_HOME% echo %ANDROID_SDK_ROOT%看看这两个变量指向哪里。如果它们指向的 SDK 目录里没有android-35就说明你被环境变量带到沟里去了。处理方式有两种要么把环境变量改成正确 SDK 的路径要么直接在local.properties里明确写死sdk.dir。我比较推荐第二种因为环境变量是全局性的改错了会影响其他项目。local.properties只对当前项目生效隔离性更好。4.3 路径已经正确仍然报错时的进阶排查有一种情况比较罕见但也真实存在android.jar文件确实存在路径也正确但 Gradle 就是读不了文件。优先级从高到低排查三件事文件权限问题。Windows 上某些从压缩包解压出来的 SDK 文件夹会被系统标记为“来自其他计算机”右键点击android-35文件夹选择“属性”在“常规”标签页最下方看有没有“解除锁定”按钮有的话点掉。杀毒软件拦截。某些安全软件会把android.jar当作可疑文件隔离。去杀毒软件的隔离区里翻一下把 SDK 目录加入白名单。磁盘写入保护。老旧的移动硬盘或只读权限的目录也会导致这种情况把 SDK 拷到本地磁盘再试一次。5. 解法 CGradle 自动下载缺失 Platform 的机制与应急降级5.1 自动下载机制为什么会失灵Android Studio 在 Sync 的时候理论上会自动发现缺失的 SDK Platform并弹出一个提示框让你确认下载。但实际使用中这个机制经常“静默失败”。常见原因有三个网络环境限制SDK 组件需要从远程仓库下载下载被中断后没有重试提示。之前点过“不再提示”之后就一直不自动装了。命令行构建模式下AGP 不会主动触发 SDK 组件下载直接报错。所以不要依赖自动补装。发现问题之后主动去 SDK Manager 或直接用sdkmanager安装永远是最稳定的路径。5.2 应急修改 compileSdk 降级如果项目不依赖 API 35 的新特性而你又急需把项目跑起来或打包可以临时把compileSdk降到本地已有的 Platform 版本。在app/build.gradle里android { compileSdk 34 defaultConfig { targetSdk 34 } }如果用 Kotlin DSL也就是app/build.gradle.ktsandroid { compileSdk 34 defaultConfig { targetSdk 34 } }注意这只是应急。如果项目代码里使用了 API 35 才有的类或方法降级之后会出现编译错误。到时候你会看到类似error: cannot find symbol的提示那就没法靠降级逃避了老老实实安装 Platform 35 才是正解。5.3 命令行/CI 环境下的 SDK 预装如果你在 CI 上构建 Android 项目服务器往往是没有图形界面的这个报错更容易出现。正确的做法是在构建脚本里先把需要的 Platform 装好。Windows 批处理示例sdkmanager.bat --install platforms;android-35 sdkmanager.bat --licenses gradlew.bat assembleDebugLinux/macOS 示例sdkmanager --install platforms;android-35 yes | sdkmanager --licenses ./gradlew assembleDebug这一步相当于把本地手动安装的动作自动化了。CI 环境里不要指望 AGP 自动补装自己动手才能保证每一次构建环境都是完整的。6. 十分钟排查链路复盘与后续防坑习惯6.1 五步走快速定位如果你不想从头看文章只看这一段就够了。遇到failed to load include path ... android-35\android.jar按这个顺序排查看报错路径指向哪个 SDK 目录。记住这个路径后面所有判断都以它为准。打开 SDK Manager检查 Android SDK Platform 35 是否已安装。没装就装上装完重启 Android Studio。检查 local.properties 里的 sdk.dir 是否和报错路径一致。不一致就改过来。检查 ANDROID_HOME 和 ANDROID_SDK_ROOT 环境变量。确认没有指向一个残废的 SDK 路径。确认 android.jar 文件真实存在。存在还报错就执行 Invalidate Caches / Restart并停掉 Gradle daemon。这一套流程走下来从发现问题到解决基本就是十分钟以内的事。6.2 实战补充案例路径里带空格的坑我在排查过程中还见过一个很有意思的案例。有台机器的 Android SDK 装在D:\Program Files\Android\Sdk路径里带了空格。部分老版本的 Gradle 和 NDK 对这种路径处理得不好会间歇性报failed to load include path有时候重新 Sync 一次又好了过一阵又犯。遇到这种问题最省心的方案是把 SDK 挪到一个没有空格、最好是全英文的路径下比如D:\Android\Sdk。路径带中文也是一样的道理虽然不是百分百报错但为了少浪费人生建议一开始就避开。6.3 容易混淆的相似报错一览实际排查中有几个报错长得不一样根因却很接近。这里列个表方便你对照报错信息真实原因处理方向failed to load include path ... android-35\android.jarSDK 里缺 Platform 35或 SDK 路径配置错误安装 Platform 35检查 local.properties / 环境变量Failed to find target with hash string android-35构建系统按 compileSdk 找 Platform 35 找不到同上本质就是缺 PlatformPackage android.content does not existandroid.jar 没进编译类路径常见于缺 Platform 或依赖配置错误检查 compileSdk 对应的 Platform 是否完整SDK location not found. Define a valid SDK location完全没有配置 SDK 路径创建 local.properties 并填写 sdk.dir6.4 团队协作中的 SDK 版本同步习惯最后说一个团队协作层面的建议。多人维护同一个项目时compileSdk版本是所有开发者的硬性要求。你在代码里写了compileSdk 35就意味着团队里每个人本机都要有 Platform 35。我自己的习惯是在项目 README 里加一段“环境要求”写清楚需要的 SDK Platform 版本。新建项目时也会在提交代码前确认一下local.properties没有被误提交。如果团队经常换人还可以在仓库里放一个local.properties.example文件内容写好 sdk.dir 的格式说明让新同事拷过去改一下路径就能用。SDK 版本管理这种事看起来是小事但每次遇到failed to load include path的人都在同一块石头上绊倒。把这些防坑机制做在前面省下的调试时间比想象中多得多。我在实际处理这个报错时最大的体会是先看路径再开 SDK Manager最后才动配置文件。顺序反了容易越改越乱尤其是 Windows 环境下很多问题不是 SDK 没装而是路径对不上。希望大家看到这个报错时能想起这篇文章别再被它吓住。 
长河君 · 2026/10/3 1:19:23 · 阅读 1.2k Gradle报错failed to load include path android.jar缺失的根治方案
如果你在 Android Studio 的 Build 窗口里看到这么一行报错——failed to load include path C:\Users\你的用户名\AppData\Local\Android\Sdk\platforms\android-35\android.jar——大概率不是你代码写错了而是 Gradle 在编译的第一步就找不到对应 API Level 的 android.jar。我第一次遇到这个问题时差点把整个项目重新 clone 了一遍后来才发现真正原因就是 Android SDK Platform 35 没装。而这个报错最坑的地方在于它不会明说“请安装 Platform 35”只会丢给你一个“include path 加载失败”看起来像是工程配置坏了实际却不是。这篇文章我会把这个报错从出现场景、根因拆解、解决手段到防坑习惯完整过一遍覆盖 Android Studio 图形界面、命令行 Gradle 和 CI 构建三种场景。适合刚拿到别人项目的新手也适合被这个问题反复折腾的老开发。只要跟着章节走完基本能一次性解决。1. 报错现场还原它究竟在哪个环节冒出来1.1 三种高频出现场景这个报错不是只在一个地方出现。我整理了一下自己踩坑和帮别人排查的经验基本集中在三种场景里场景一打开同事发给你的项目。你本地没有这个项目clone 下来之后 Android Studio 自动开始 Gradle SyncSync 可能都显示成功了但一跑 Build 就报这个错。这种场景里问题通常出在同事的compileSdk用的是 35而你本地 SDK 里根本没有platforms\android-35这个目录。场景二手动升级了 compileSdk 版本。原来项目是compileSdk 34你想用新 API就把app/build.gradle里的版本改成了 35。改完点 Sync结果 Build 阶段立刻报错。原因很简单只改了数字没让 SDK Manager 把 Platform 35 下载到本地。场景三命令行直接跑gradlew.bat assembleDebug。这种最常见于习惯用终端构建的人。Android Studio 在 Sync 的时候有自动补装 SDK 组件的能力但命令行默认不会做这件事。你如果在命令行环境里直接构建而本地没有对应 Platform报错就会非常干脆。1.2 报错信息的真实含义要理解这个报错先要明白android.jar是干什么的。Android 应用编译的时候你的代码会引用android.app.Activity、android.os.Bundle这些系统类。这些类不是随便从网上拉的而是由 SDK 里对应版本的android.jar提供的。Gradle 在编译期会把android.jar加到编译类路径里作用相当于 JDK 里的rt.jar。所以你看报错信息里的include path指的就是编译时要引入的系统库路径。当你的compileSdk被设置为 35Android Gradle Plugin 就会去 SDK 目录下寻找platforms\android-35\android.jar。找不到就报failed to load include path。说白了这不是语法错误也不是依赖冲突就是一个简单的“文件不存在”问题。1.3 哪些人更容易踩中这个坑我总结了一下遇到这个问题的人通常有以下特征刚装好 Android Studio 不久SDK 里只有默认自带的几个 Platform比如android-34或者android-33。电脑上有多个 Android SDK 目录环境变量ANDROID_HOME指向的是旧目录。备份系统或者重装系统之后SDK 是从旧硬盘直接拷过来的目录不完整。项目是别人维护的compileSdk版本高于你本地所有 Platform。2. 根源拆解SDK 明明在为什么就是找不到 android.jar2.1 compileSdk35Platform 35 却没安装很多人对 SDK 的组成有误解以为装了 Android Studio 就等于装了所有版本。实际上Android Studio 安装包只附带一个默认的 SDK Platform。你新建项目时如果选了某个 API Level它可能帮你补装但如果是别人建好的项目直接拷过来就不会自动补。SDK Manager 里的组件分得很细Platforms目录下只有一个版本对应一个android-XX文件夹Build-Tools是独立的一套Sources for Android XX又是另外一套。你需要的android.jar只存在于Platforms目录下对应的文件夹里。只装了 Build-Tools或者只装了 Sources都没用android.jar不会自己出现。2.2 local.properties 里的 sdk.dir 指错了位置local.properties是 Android Studio 在项目根目录自动生成的一个文件里面记录着本地 SDK 路径关键字段是sdk.dir。这个文件不纳入版本管理每个开发者机器上都不一样。问题来了如果你的 SDK 实际上装在D:\Android\Sdk但local.properties里写的却是C:\Users\xxx\AppData\Local\Android\Sdk那 Gradle 去找D:\Android\Sdk\platforms\android-35时当然找不到。报错信息里的路径可能不是真实存在的路径而是配置里写错的那个路径。我见过最夸张的一个例子是从 Mac 上拷过来的项目local.properties里还是/Users/xxx/Library/Android/sdk这种 Unix 格式路径。拿到 Windows 上当然一跑一个准。2.3 环境变量把 Gradle 带偏了ANDROID_HOME和ANDROID_SDK_ROOT这两个环境变量在 Android 开发里是老演员了。很多教程让你安装完 SDK 后去系统环境变量里配置ANDROID_HOME本意是方便命令行使用。但问题在于环境变量指向的 SDK 目录和 Android Studio 里配置的 SDK 目录可能是两个地方。Gradle 在解析 SDK 路径时local.properties里的sdk.dir优先级最高如果这个文件不存在或者没写才会去看环境变量。有些老项目压根没生成local.properties那 Gradle 就会跟着ANDROID_HOME走。一旦ANDROID_HOME指向一个残缺的 SDK报错就会出现。2.4 SDK 目录迁移和精简留下的后遗症还有一类人电脑磁盘不够用发现platforms目录下全是“用不上”的旧版本就手动删掉了几个文件夹比如删了android-31、android-32觉得反正没在用。结果下一个项目就要求compileSdk 32立刻就报错。另外从别人那里拷贝的 SDK 也存在这种问题。网上下载的“绿色版 SDK”经常是精简过的可能只有最新一个 Platform。这种 SDK 平时用着还行一旦遇到版本跨度大的项目就非常容易出问题。不要问我是怎么知道的我在一台测试机上吃过同样的亏。3. 解法 A把 android-35 Platform 装全图形界面和命令行都来一遍3.1 Android Studio SDK Manager 图形安装这是最省心、也最不容易出错的方法。打开 Android Studio按顺序走一遍点击菜单栏Tools选择SDK Manager。在弹出的窗口里切到SDK Platforms标签页。在列表里找到Android SDK Platform 35勾选上。点击右下角Apply等待下载完成。完成后点OK关闭窗口。这里有个细节列表里有好几项都带“35”比如Android SDK Platform 35、Sources for Android 35、Google APIs等。你要勾选的是Android SDK Platform 35没有这个基础包装其他组件都没意义。Google APIs一般不用单独勾除非项目明确用到。安装完成后去 SDK 目录下检查一下platforms\android-35\android.jar是否存在。如果存在回到 Android Studio 重新 Sync 一次再 Build这个问题基本就消失了。3.2 命令行 sdkmanager 精确安装如果你习惯用终端构建或者在 Android Studio 的 SDK Manager 里因为网络问题下载失败可以改用命令行工具sdkmanager。先找到sdkmanager的位置。Windows 上一般在你的SDK目录\cmdline-tools\latest\bin\sdkmanager.bat如果你安装了最新版 Android Studiocmdline-tools通常都已经存在。打开终端进入这个目录执行sdkmanager.bat platforms;android-35如果你用的是 macOS 或 Linux命令是sdkmanager platforms;android-35执行过程中如果提示需要接受 license先运行sdkmanager.bat --licenses然后一路输入y接受全部协议。这一步一定要做因为很多自动安装失败的原因就是 license 没接受Gradle 的自动补装机制在这种情况下会静默放弃。装完之后可以用下面的命令确认sdkmanager.bat --list_installed或者在 Windows 终端里用dir检查dir 你的SDK目录\platforms\android-35\android.jar能看到文件就说明装好了。3.3 安装后的验证与 Gradle 缓存刷新很多时候装完 Platform回到 Android Studio 直接 Build 还是报错。别急着怀疑解法不对大概率是 Gradle daemon 还在用旧的编译环境。我自己的操作顺序是关闭 Android Studio。在终端执行gradlew.bat --stop把 Gradle daemon 停掉。重新打开 Android Studio执行File Invalidate Caches / Restart。等待索引重建再 Build。这一套下来90% 的“装完了还报错”都能解决。Gradle daemon 有时候会缓存旧的 SDK 路径信息你不主动停掉它它就一直按老记忆办事。4. 解法 B路径和配置问题的逐个修正4.1 修正 local.properties 里的 sdk.dir如果你已经确认platforms\android-35\android.jar在某个真实的 SDK 目录下存在但 Android Studio 还是报错指向另一个路径那就必须检查local.properties了。打开项目根目录找到local.properties看sdk.dir的值是不是你实际 SDK 的路径。Windows 上的写法要格外注意转义正确的例子是sdk.dirC\:\\Users\\你的用户名\\AppData\\Local\\Android\\Sdk这里反斜杠前面都加了转义符。如果你嫌麻烦也可以把路径里的反斜杠改成正斜杠Gradle 是认正斜杠的sdk.dirC:/Users/你的用户名/AppData/Local/Android/Sdk如果你的项目没有local.properties那就手动新建一个把上面这一行填进去。这里要劝一句local.properties是本地环境配置不要提交到 Git。每次在新机器上 clone 项目之后自己检查一下这个文件是个好习惯。4.2 理清环境变量的优先级环境变量和local.properties之争是这一类报错的深层原因。Android Gradle Plugin 解析 SDK 路径的顺序大致是local.properties里的sdk.dir最优先其次是ANDROID_HOME最后是ANDROID_SDK_ROOT。所以我建议你做一次完整排查在 Windows 终端里执行echo %ANDROID_HOME% echo %ANDROID_SDK_ROOT%看看这两个变量指向哪里。如果它们指向的 SDK 目录里没有android-35就说明你被环境变量带到沟里去了。处理方式有两种要么把环境变量改成正确 SDK 的路径要么直接在local.properties里明确写死sdk.dir。我比较推荐第二种因为环境变量是全局性的改错了会影响其他项目。local.properties只对当前项目生效隔离性更好。4.3 路径已经正确仍然报错时的进阶排查有一种情况比较罕见但也真实存在android.jar文件确实存在路径也正确但 Gradle 就是读不了文件。优先级从高到低排查三件事文件权限问题。Windows 上某些从压缩包解压出来的 SDK 文件夹会被系统标记为“来自其他计算机”右键点击android-35文件夹选择“属性”在“常规”标签页最下方看有没有“解除锁定”按钮有的话点掉。杀毒软件拦截。某些安全软件会把android.jar当作可疑文件隔离。去杀毒软件的隔离区里翻一下把 SDK 目录加入白名单。磁盘写入保护。老旧的移动硬盘或只读权限的目录也会导致这种情况把 SDK 拷到本地磁盘再试一次。5. 解法 CGradle 自动下载缺失 Platform 的机制与应急降级5.1 自动下载机制为什么会失灵Android Studio 在 Sync 的时候理论上会自动发现缺失的 SDK Platform并弹出一个提示框让你确认下载。但实际使用中这个机制经常“静默失败”。常见原因有三个网络环境限制SDK 组件需要从远程仓库下载下载被中断后没有重试提示。之前点过“不再提示”之后就一直不自动装了。命令行构建模式下AGP 不会主动触发 SDK 组件下载直接报错。所以不要依赖自动补装。发现问题之后主动去 SDK Manager 或直接用sdkmanager安装永远是最稳定的路径。5.2 应急修改 compileSdk 降级如果项目不依赖 API 35 的新特性而你又急需把项目跑起来或打包可以临时把compileSdk降到本地已有的 Platform 版本。在app/build.gradle里android { compileSdk 34 defaultConfig { targetSdk 34 } }如果用 Kotlin DSL也就是app/build.gradle.ktsandroid { compileSdk 34 defaultConfig { targetSdk 34 } }注意这只是应急。如果项目代码里使用了 API 35 才有的类或方法降级之后会出现编译错误。到时候你会看到类似error: cannot find symbol的提示那就没法靠降级逃避了老老实实安装 Platform 35 才是正解。5.3 命令行/CI 环境下的 SDK 预装如果你在 CI 上构建 Android 项目服务器往往是没有图形界面的这个报错更容易出现。正确的做法是在构建脚本里先把需要的 Platform 装好。Windows 批处理示例sdkmanager.bat --install platforms;android-35 sdkmanager.bat --licenses gradlew.bat assembleDebugLinux/macOS 示例sdkmanager --install platforms;android-35 yes | sdkmanager --licenses ./gradlew assembleDebug这一步相当于把本地手动安装的动作自动化了。CI 环境里不要指望 AGP 自动补装自己动手才能保证每一次构建环境都是完整的。6. 十分钟排查链路复盘与后续防坑习惯6.1 五步走快速定位如果你不想从头看文章只看这一段就够了。遇到failed to load include path ... android-35\android.jar按这个顺序排查看报错路径指向哪个 SDK 目录。记住这个路径后面所有判断都以它为准。打开 SDK Manager检查 Android SDK Platform 35 是否已安装。没装就装上装完重启 Android Studio。检查 local.properties 里的 sdk.dir 是否和报错路径一致。不一致就改过来。检查 ANDROID_HOME 和 ANDROID_SDK_ROOT 环境变量。确认没有指向一个残废的 SDK 路径。确认 android.jar 文件真实存在。存在还报错就执行 Invalidate Caches / Restart并停掉 Gradle daemon。这一套流程走下来从发现问题到解决基本就是十分钟以内的事。6.2 实战补充案例路径里带空格的坑我在排查过程中还见过一个很有意思的案例。有台机器的 Android SDK 装在D:\Program Files\Android\Sdk路径里带了空格。部分老版本的 Gradle 和 NDK 对这种路径处理得不好会间歇性报failed to load include path有时候重新 Sync 一次又好了过一阵又犯。遇到这种问题最省心的方案是把 SDK 挪到一个没有空格、最好是全英文的路径下比如D:\Android\Sdk。路径带中文也是一样的道理虽然不是百分百报错但为了少浪费人生建议一开始就避开。6.3 容易混淆的相似报错一览实际排查中有几个报错长得不一样根因却很接近。这里列个表方便你对照报错信息真实原因处理方向failed to load include path ... android-35\android.jarSDK 里缺 Platform 35或 SDK 路径配置错误安装 Platform 35检查 local.properties / 环境变量Failed to find target with hash string android-35构建系统按 compileSdk 找 Platform 35 找不到同上本质就是缺 PlatformPackage android.content does not existandroid.jar 没进编译类路径常见于缺 Platform 或依赖配置错误检查 compileSdk 对应的 Platform 是否完整SDK location not found. Define a valid SDK location完全没有配置 SDK 路径创建 local.properties 并填写 sdk.dir6.4 团队协作中的 SDK 版本同步习惯最后说一个团队协作层面的建议。多人维护同一个项目时compileSdk版本是所有开发者的硬性要求。你在代码里写了compileSdk 35就意味着团队里每个人本机都要有 Platform 35。我自己的习惯是在项目 README 里加一段“环境要求”写清楚需要的 SDK Platform 版本。新建项目时也会在提交代码前确认一下local.properties没有被误提交。如果团队经常换人还可以在仓库里放一个local.properties.example文件内容写好 sdk.dir 的格式说明让新同事拷过去改一下路径就能用。SDK 版本管理这种事看起来是小事但每次遇到failed to load include path的人都在同一块石头上绊倒。把这些防坑机制做在前面省下的调试时间比想象中多得多。我在实际处理这个报错时最大的体会是先看路径再开 SDK Manager最后才动配置文件。顺序反了容易越改越乱尤其是 Windows 环境下很多问题不是 SDK 没装而是路径对不上。希望大家看到这个报错时能想起这篇文章别再被它吓住。