为什么对本机库有 API 限制？
Why is there an API limit on native libraries?
在寻找用于 Android 应用程序的本机 key/value 存储库时，我尝试使用 hsearch，但在我的 "old" 上尝试部署时phone (API 23), 我得到一个错误: "undefined reference to 'hcreate'".
通过 Android Studio 研究 search.h，我发现这些功能只能用于 API 级别以上或等于 search.h.
中的 28（声明受 #if __ANDROID_API__ >= 28 保护）
Android API 28 于 2018 年 8 月发布，我相信 hsearch 比它更老，所以问题是：为什么hsearch 函数有这么高的 API 限制？
Probably only the responsible developers at Google can answer the "why" definitively.
那就是我:-)
从历史上看，正如您所说，仿生基本上是“足够的 libc 来构建 dalvik”。在从 dalvik 到 ART 的过渡期间，我从事 ART 工作并花了足够的时间修复 libc 问题——当需要添加 64 位支持时——我最终拥有了 libc。
您可以看到 Android bionic status 从我最早参与仿生学到现在所发生的事情，以及“还剩下什么”。具体来说，现在实际上只有一小部分“我们绝对不会添加的内容”，我们会努力确保始终在该页面的顶部对其进行解释。
如果您查看该页面，您会注意到 L —— 那是我基本上开始 full-time 在 libc 上工作的时候 —— 是大多数缺失内容出现的地方。所以在 的特定情况下，问题仍然是“为什么将这些添加到 API 28 而不是 API 21？”。这个问题的答案，我记得基本上是 (a) 我认为当时我们从未见过使用这些函数的任何代码和 (b) 它们看起来应该被弃用。非 _r 形式不适合从库代码中使用 table，例如，因为它们在单个全局 table.
上运行
在某个时候有人提出了使用它的 third-party 代码，我捏着鼻子添加了它。我的一部分仍然想知道我们是否应该只添加 _r 变体，但是由于 C 只是一个大 foot-gun 无论如何，我觉得“它只是工作”的积极价值超过了消极价值“几乎没有代码应该使用它，我们也没有很好的方法来帮助您发现错误”。
just because glibc has feature X doesn't automatically mean that it will make its way over to bionic
我们确实尝试跟踪 glibc 添加的内容，看看是否有任何有用的内容，但就可移植性而言，iOS 与大多数 Android 开发人员更相关。 （例如，glibc qsort_r 和 iOS qsort_r 之间的冲突是 Android 仍然没有任何一个的原因！）
As for why they didn't backport the feature to older API levels when they did add it to bionic, I don't know.
none 这些案例是安全问题，因此他们没有资格进行次要更新。
在某些情况下，我们确实在 headers 中有针对旧 API 级别的函数的内联版本。例如：termios_inlines.h
回到这个具体案例，hcreate/hsearch/hdestroy 函数既小又简单，所以如果您需要它们，您总是可以直接将它们包含在您的代码中。这是 Android（来自 FreeBSD）中当前使用的：source。但请记住，您也有 libc++ 可用，因此 std::map 和朋友很容易获得，通常是更好的选择。 （这也是为什么这么长时间都没有出现需求的原因之一。）
在寻找用于 Android 应用程序的本机 key/value 存储库时，我尝试使用 hsearch，但在我的 "old" 上尝试部署时phone (API 23), 我得到一个错误: "undefined reference to 'hcreate'".
通过 Android Studio 研究 search.h，我发现这些功能只能用于 API 级别以上或等于 search.h.
中的 28（声明受#if __ANDROID_API__ >= 28 保护）
Android API 28 于 2018 年 8 月发布，我相信 hsearch 比它更老，所以问题是：为什么hsearch 函数有这么高的 API 限制？
Probably only the responsible developers at Google can answer the "why" definitively.
那就是我:-)
从历史上看，正如您所说，仿生基本上是“足够的 libc 来构建 dalvik”。在从 dalvik 到 ART 的过渡期间，我从事 ART 工作并花了足够的时间修复 libc 问题——当需要添加 64 位支持时——我最终拥有了 libc。
您可以看到 Android bionic status 从我最早参与仿生学到现在所发生的事情，以及“还剩下什么”。具体来说，现在实际上只有一小部分“我们绝对不会添加的内容”，我们会努力确保始终在该页面的顶部对其进行解释。
如果您查看该页面，您会注意到 L —— 那是我基本上开始 full-time 在 libc 上工作的时候 —— 是大多数缺失内容出现的地方。所以在 _r 形式不适合从库代码中使用 table，例如，因为它们在单个全局 table.
在某个时候有人提出了使用它的 third-party 代码，我捏着鼻子添加了它。我的一部分仍然想知道我们是否应该只添加 _r 变体，但是由于 C 只是一个大 foot-gun 无论如何，我觉得“它只是工作”的积极价值超过了消极价值“几乎没有代码应该使用它，我们也没有很好的方法来帮助您发现错误”。
just because glibc has feature X doesn't automatically mean that it will make its way over to bionic
我们确实尝试跟踪 glibc 添加的内容，看看是否有任何有用的内容，但就可移植性而言，iOS 与大多数 Android 开发人员更相关。 （例如，glibc qsort_r 和 iOS qsort_r 之间的冲突是 Android 仍然没有任何一个的原因！）
As for why they didn't backport the feature to older API levels when they did add it to bionic, I don't know.
none 这些案例是安全问题，因此他们没有资格进行次要更新。
在某些情况下，我们确实在 headers 中有针对旧 API 级别的函数的内联版本。例如：termios_inlines.h
回到这个具体案例，hcreate/hsearch/hdestroy 函数既小又简单，所以如果您需要它们，您总是可以直接将它们包含在您的代码中。这是 Android（来自 FreeBSD）中当前使用的：source。但请记住，您也有 libc++ 可用，因此 std::map 和朋友很容易获得，通常是更好的选择。 （这也是为什么这么长时间都没有出现需求的原因之一。）