如何使Android应用兼容API Level 14以下版本？

首先，结合你的核心需求——临时兼容至API10，仅修复导出数据的关键bug，无需长期维护低版本，我会优先推荐你选择方案1，同时它本身也能实现方案3的多APK发布效果，理由如下：

各方案优劣分析 #

方案1：分产品变种使用不同版本Support Library #

这是最适配你需求的方案，优势很明显：

• 无需大幅重构现有代码：你只需在build.gradle中配置两个产品变种（比如oldApi和normal），分别指定不同的minSdkVersion和对应的Support Library版本（25.4.0的最低兼容版本是API7，完全覆盖API10的需求）。
• 维护成本极低：因为只是临时修复，你只需要确保oldApi变种中负责导出数据的核心代码在API10环境下正常运行即可，非核心功能如果依赖高版本API，用@TargetApi注解或运行时版本判断就能轻松规避。
• 版本发布互不干扰：高版本系统用户会自动获取使用新版Support Library的正常APK，低版本用户则拿到兼容版，完全不会影响现有用户体验。

配置示例（简化版）：

android {
    ...
    productFlavors {
        oldApi {
            minSdkVersion 10
            versionCode 1001 // 单独设置版本号，方便后台区分统计
            versionName "1.0-oldApi"
        }
        normal {
            minSdkVersion 15
            versionCode 2001
            versionName "2.0"
        }
    }

    dependencies {
        oldApiImplementation 'com.android.support:appcompat-v7:25.4.0'
        // 其他依赖也要同步降到兼容25.4.0的版本，比如recyclerview、design等
        normalImplementation 'com.android.support:appcompat-v7:27.1.1'
        // 正常版本的依赖配置保持不变
    }
}

方案2：弃用Support Library改用原生方法 #

这个方案的代价太高，完全不推荐：

• 你需要把所有依赖Support Library的组件（比如AppCompatActivity、Toolbar等）全部替换成原生系统组件，这涉及大量代码重构，对于临时修复来说完全是舍近求远。
• 原生组件在低版本系统中的表现差异极大，可能会引入新的兼容性问题，反而增加调试成本。

方案3：多APK发布 #

其实方案1已经包含了多APK发布的逻辑，如果你单独做一个仅包含导出功能的精简APK，反而需要维护另一个独立的代码分支或项目，工作量比方案1大得多，性价比极低。

有没有更简便的方法？ #

绝对不建议使用tools:overrideLibrary="android.support.v7.appcompat"强制覆盖minSdk限制，因为Support Library 27.1.1确实使用了API14及以上的系统API，在API10设备上运行时必然会出现NoSuchMethodError或类似崩溃，风险极高，完全不符合你修复bug的核心目标。

总结下来，方案1是兼顾成本、风险和需求的最优选择，等低版本用户的bug修复完成后，你可以直接废弃oldApi变种，回到原有版本的开发流程。

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