Android Studio Sync Failed记录
背景介绍
修复系统后重新安装了Android Studio，例行Hello World, 下载gradle插件时久违地碰到了Sync Failed，回想全面爬梯前被这个问题支配的恐惧，觉得有必要单开一帖记录一下。
网络环境
已爬梯，全局模式。
未配置Android Studio内部爬梯功能
build.gradle为默认配置
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27// Top-level build file where you can add configuration options common to all sub-projects/modules.
buildscript {
ext.kotlin_version = "1.5.0"
repositories {
mavenCentral()
google()
}
dependencies {
classpath 'com.android.tools.build:gradle:4.2.1'
classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
// NOTE: Do not place your application dependencies here; they belong
// in the individual module build.gradle files
}
}
allprojects {
repositories {
mavenCentral()
google()
jcenter() // Warning: this repository is going to shut down soon
}
}
task clean(type: Delete) {
delete rootProject.buildDir
}
问题描述
- gradle可正常下载
- 部分依赖可正常下载
- 报错time out，无法下载Could not resolve com.android.tools.build:gradle:4.2.1.
尝试记录
第一反应是之前看到过的jcenter被废弃，去官网看了下公告，服务到明年，排除这个原因。
试了试之前的老办法，添加国内的一些仓库，增加了阿里云的，没有用，一开始推测是gradle-4.2.1.pom属于比较新的版本，阿里云仓库中还未同步更新，因此最后还是会从google仓库中去下载。仍然提示time_out，而给出的下载地址在浏览器中可以正常访问，因此应该是爬梯软件在Android Studio上没起作用。因此得出解决方法有二：
- 选择较老的gradle及gradle-plugin版本从阿里云下载
- 在Android Studio内配置好爬梯功能
决定选择先试第一种方法，有一点需要注意的是，gradle版本需要和gradle插件版本匹配。
经测试仍然失败，Could not find com.android.tools.build:gradle:3.6.4.
Searched in the following locations，阿里云中似乎没有任何一个版本的gradle-plugin，之前的推测是错误的。最终还是转向“在Android Studio内配置好爬梯功能”这条路。
顺便想了一下，之前实习时没碰到这些问题应该是当时在一家做海外业务的公司，网络环境默认爬梯。
在Android Studio Setting中设置代理，由于Android Studio外是全局代理，所以直接代理到127.0.0.1。这里有个小坑是设置的代理协议（socks或者HTTP）还有端口，要根据当前使用的爬梯软件的配置来填，切忌抄博客填个1080或者其他的，网上大多数针对Android Studio爬梯配置的博客用的一般是小飞机，本人是v2，socks协议+10808端口。这里端口如果设置错了会出现connect refused报错。
最后有一点要注意的是，当你开始同步时Android Studio会提醒你是否给gradle也添加代理，这一步如果不仔细读会认为是对之前代理设置的一个确认。对你控制变量排查网络错误造成一定的迷惑，其实这一步是给用户目录下/.gradle目录里的gradle设置了代理。如果你选择了🆗，把Android Studio的代理应用到了gradle上，如果之后要取消代理或者修改端口，要记得也更新此处。
配置完代理，各种依赖就迅速下载成功了。
一些总结
一开始碰到问题的时候盲目照搬搜索引擎解决方案，没有试图去理解问题，这是一个糟糕的习惯。这种做法的出发点可能是速战速决，毕竟网络问题不是我们能左右的，就不想深挖，但实际上也给解决问题埋了坑，搬了一些并不适用的方法，如此几次，又变得有些浮躁。
最后解决问题还是靠笨办法控制变量，找出症结所在，最后发现是一个很简单的问题。这件事虽然和开发无关，但是和一些人解决开发问题的方向是类似的（在查找博客过程中见到不少案例），所以还是值得反思。
gradle脚本的学习，机制的理解也应该提上日程了。
一些参考
https://blog.csdn.net/fuchaosz/article/details/51567808
https://www.jianshu.com/p/7a16793cefb0
https://www.jianshu.com/p/8529dc82f812
https://blog.csdn.net/wangzhongshun/article/details/104898953
https://blog.csdn.net/liuli905306022/article/details/89927052