Android开发中minCompileSdk与compileSdk的区别是什么

两个配置完全属于不同维度的规则，具体区别如下：

基础定义 #

• compileSdk：是开发者在模块级构建脚本里自行配置的项目编译参数，指当前项目编译阶段使用的Android SDK版本。它决定了编译期可调用的系统API范围、lint检查的规则基准，仅作用于编译环节，不会直接影响应用在真机上的运行时行为。
• minCompileSdk：是第三方依赖（比如AppCompat这类AndroidX库）发布时内置的强制约束，代表该依赖要求宿主项目必须达到的最低编译SDK版本门槛，不需要开发者手动配置，是依赖方提前写入依赖元数据的准入要求。

核心差异 #

• 控制权不同
  compileSdk的配置权完全在项目开发者手中，可根据项目需求自行选择版本；minCompileSdk的规则由依赖库发布方制定，使用方只能选择满足要求，或者换用更低版本的依赖。
• 校验逻辑不同
  构建过程中AGP会自动比对项目配置的compileSdk和所有依赖声明的minCompileSdk：只要compileSdk版本大于等于所有依赖的minCompileSdk要求，编译就能正常通过；如果compileSdk版本低于某个依赖的minCompileSdk阈值，构建会直接失败，提示需要升级项目编译SDK版本。
• 作用范围不同
  compileSdk是整个项目编译行为的基准：比如配置compileSdk = 33，就能正常调用Android 13的所有公开平台API，要是直接调用Android 14才新增的API，lint会直接报编译错误；minCompileSdk只是依赖给出的最低准入线，比如AppCompat 1.6.0-alpha05要求minCompileSdk = 33，把项目compileSdk设为33、34甚至更高的预发布版本都可以正常适配，不存在版本过高不兼容的问题。

补充提醒：这两个参数都和应用的运行时兼容性无关，不要和minSdk（应用支持的最低安卓系统版本）搞混。哪怕你用compileSdk = 34、依赖要求minCompileSdk =33，只要没调用高版本专属API、或者做了正确的版本分支判断，应用照样可以在低版本安卓系统上正常运行。

内容的提问来源于stack exchange，提问作者Bitwise DEVS