关于 SO 的压倒性建议是编译 SDK 通常应该与目标 SDK 匹配。
同样建议让这个 [compileSdk] 匹配你的目标 sdk 版本。
... CompileSDK（通常等于目标 SDK 版本）版本。
但明确的advice here 是：
一般来说，您应该针对您的应用程序可以支持的平台的最低版本编译您的应用程序。
我一直让 compile sdk 匹配目标 sdk，但是自从阅读后我意识到我和许多 SO 的答案都是错误的。
我的问题是，让它们匹配有什么害处，或者相反，拥有最低编译 sdk 版本的优势是什么？
【问题讨论】：
标签： android
关于 SO 的压倒性建议是编译 SDK 通常应该与目标 SDK 匹配。
真的吗？我预计很少有生产 Android 应用程序会如此配置，除了新创建的项目，新项目向导倾向于为这些项目设置相同的值。
让它们匹配有什么害处
使它们匹配并没有特别的危害。使它们不匹配并没有特别的危害。这完全取决于你在写什么以及你想要什么样的行为。
例如，Android 6.0 引入了一种新的运行时权限模型，您必须在应用中添加代码以向用户请求危险权限，从 WRITE_EXTERNAL_STORAGE 到 READ_CONTACTS。但是，这仅在 targetSdkVersion 为 23 或更高时使用。如果您现在无法处理该代码更改，您可以特别将您的 targetSdkVersion 保留在较低的位置，例如 22。
但是，与此同时，您可能想要使用关键 Android 支持库的 v23 版本，例如 appcompat-v7。一般来说，您会希望您的 compileSdkVersion 与您正在使用的支持库的主要版本相匹配，因为它们可能引用类、方法、常量等，这些仅在该 compileSdkVersion 中可用。
因此，这将是您特别不希望 compileSdkVersion 匹配 targetSdkVersion 的情况。
拥有最低的 compile sdk 版本有什么好处？
现在，几乎没有优势，恕我直言。
早在 2008-2011 年，一个常见的（尽管有缺陷的）建议是让 compileSdkVersion 匹配 minSdkVersion（或者，事实上，它们的 Eclipse/Ant 等价物，因为当时不存在 Android Studio）。这是因为我们缺乏工具来自动告诉我们是否使用了在我们的compileSdkVersion（例如，11）中有效但在我们的minSdkVersion（例如，4）中一直不可用的东西。将这两个值设置为相等意味着如果您尝试使用比minSdkVersion 更新的东西，则会出现编译器错误。缺点是您被 minSdkVersion 中的功能集所困，无法逐步增强您的应用程序以利用新设备上可用的新功能。
现在，如果您尝试使用在您的 compileSdkVersion 中有效但在回到 minSdkVersion 时一直不可用的东西，构建工具（特别是 Lint）会对您大喊大叫，因此您知道放入适当的Build.VERSION.SDK_INT 检查以确保您只在较新的设备上使用较新的东西，并在旧设备上正常降级。
【讨论】：
compileSdkVersion 需要反映库的要求，例如 Android 支持库。另外，您只是一名开发人员，我不希望许多开发人员同步更改compileSdkVersion 和targetSdkVersion。这样做并没有本质上的错误（模库要求），但仅仅因为 you 做了某事并不意味着 每个人 都做了某事。我预计会有更多的开发人员将它们视为主要的独立变量。