在 Android API24 上无法使用 BC 作为加密套件 ( SSL problems in Android )

[LamGC]

这个应该算是兼容性问题，Android P 开始将会移除 BC 加密套件（因为已经提供了 Android 上的其他加密套件），这将会导致 Proxyee 在 API 24 及以上无法使用。

要解决这个方法，需要移除对加密套件的指定，以允许 Android 为其自动提供可用的加密套件，但这个操作在 Desktop 环境显然不是很现实（除非 Java 自带的加密套件可以运用在 Proxyee），因此我想对 Proxyee 原版做一个小调整，独立出一个除 加密套件 不同外其他都与原版一样的新分支（暂定为 master-android）。

然后是提出这个 Issue 的原因：Proxyee 对于加密的所有操作都存在于 CertUtil 吗？ 希望作者能回答我，感谢！

Google 对于加密套件变更的官方文章：Cryptography changes in Android P

[monkeyWie]

@LamGC 这个加密套件的兼容性可不可以通过判断系统环境来自适应呢？ 然后目前所有的加密操作都是存在于CertUtil中，没错的。

[LamGC]

@LamGC 这个加密套件的兼容性可不可以通过判断系统环境来自适应呢？ 然后目前所有的加密操作都是存在于CertUtil中，没错的。

@monkeyWie 唔，我的想法是，如果不区分分支的话，将 CertUtil 转化为中间层（类似于 Slf4j 的 LoggerFactory），区分具体实现，然后根据需要引入（或者直接整合，按环境区分，不过这个我得确定一下）。

[monkeyWie]

这个感觉可以，或者其实提供一个自定义注册加密套件的入口就行了，把这段逻辑做成可定制的：

[LamGC]

@monkeyWie 也行，或者简单一点，为 CertUtil 提供设置提供者名称，让开发者自由选择，没设置就默认BC，或者Null选JVM默认。（这个有兼容性问题） 单纯自定义注册加密套件可能不是一个很好的方法，注册了不一定会成为首选，所以可能还是要整一套接口和实现（晚点我试试看）。

[monkeyWie]

@LamGC 嗯嗯，等看看你的实现思路

[LamGC]

这边等待 Pull Request #108 的确认了，我疏忽大意忘记了分支跟 PR 的关联性，所以需要等待 PR #108 处理完成后才能 Push 并发起 PR。

[LamGC]

补充个细节，这次更改使得 Proxyee 即使不自行实现一个 CertGenerator，也可以运用到新版 Android 了，核心问题在于 provider 不能为 BC，而不是 BouncyCastle 被禁用了，因此实际上只要不指定 Provider 就可以了。 😆

[monkeyWie]

补充个细节，这次更改使得 Proxyee 即使不自行实现一个 CertGenerator，也可以运用到新版 Android 了，核心问题在于 provider 不能为 BC，而不是 BouncyCastle 被禁用了，因此实际上只要不指定 Provider 就可以了。 😆

是新版安卓sdk内置了BC吗

[LamGC]

补充个细节，这次更改使得 Proxyee 即使不自行实现一个 CertGenerator，也可以运用到新版 Android 了，核心问题在于 provider 不能为 BC，而不是 BouncyCastle 被禁用了，因此实际上只要不指定 Provider 就可以了。 😆

是新版安卓sdk内置了BC吗

安卓实际上早就内置 BC 了，不过后来又加了几种加密套件，到 API 24 (7.0) 开始移除 BC 套件以减轻维护负担，所以就不能使用了。（具体可以看这个 issue 附上的链接）

[monkeyWie]

我比较好奇的是移除了BC,那由什么补上，谷歌自己开发了一套加密套件吗

[LamGC]

差不多，我忘记是啥了，文章有写（现在科学不了打不开）

[monkeyWie]

@LamGC 了解