Android 源无法编译?

发布于 2024-09-04 15:52:09 字数 162 浏览 9 评论 0原文

因此,我一直在查看 Android git 各个部分的代码,但是当我尝试加载和编译其中许多代码(相机、媒体播放器等)时,它们引用了甚至不可用的 SDK 的类和部分我的SDK版本更新到2.2。 (例如NativeAlloc中的位图配置选项)

是否有原因导致这些没有出现在提供给开发人员的SDK中?

So I've been looking at code from various parts of the Android git, but when I try to load and compile many of them (camera, media player, etc) they reference classes and parts of the SDK that just aren't available even with my SDK version updated to 2.2. (for example the bitmap config option inNativeAlloc)

Is there a reason that these are not in the SDK given out to developers?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

愿与i 2024-09-11 15:52:09

如果您想从 Android 开源项目 (ASOP) 编译应用程序,例如浏览器、相机、媒体播放器等。您必须在 Linux 或 Mac 上构建。您无法在 Windows 上编译源代码。

有关构建源代码和操作系统要求的信息,请参阅获取 Android 源代码

If you want to compile applications from the android open source project (ASOP), like the browser, camera, media player etc. You have to build on a Linux or Mac. You cannot compile the source on Windows.

See Get Android Source Code on info for building the source and the OS requirements requirements

执笔绘流年 2024-09-11 15:52:09

有没有理由不这样做?
在发给开发者的 SDK 中?

有多种可能性,具体取决于“这些”是什么。

我的印象是,大多数情况都是他们还没有抽出时间来处理。我所说的“尚未解决”,是指他们还没有最终确定他们想要永远坚持的类和方法签名。 Android 核心团队试图最大程度地减少版本之间 API 损坏的数量,并且通常会成功(损坏往往是行为的更改多于方法签名的更改)。获得所有利益相关者对给定代码块的支持需要付出相当大的努力。 Android 中有大量代码,其中一些可能可以放入 SDK 中,但与提升 Android 功能相比,分配给这项琐事的时间有限。

在某些情况下,答案是安全性——除了没有稳定的 API 之外,他们还不知道如何保护它,因此他们只将其提供给固件开发人员。

在某些情况下,答案可能是性能——他们适当调整了所需的用例,但外部开发人员可能会尝试其他尚未优化的用例。

我确信还有其他可能的原因。

Is there a reason that these are not
in the SDK given out to developers?

There are several possibilities, depending on what "these" are.

I am under the impression that most of the cases are that they simply have not gotten around to it yet. By "gotten around to it yet", I mean they haven't finalized the classes and method signatures they want to stick with for all time. The core Android team tries to minimize the amount of API breakage between releases, and generally succeeds (breakage tends to be more changed behaviors than changes in method signatures). Getting buy-in from all stakeholders for a given hunk of code takes a fair bit of effort. There is a ton of code in Android, some of which probably could go in the SDK, but only so much time gets allocated to that chore, compared to advancing Android capabilities.

In some cases, the answer is security -- that beyond not having a stable API, they do not know how they want to secure it yet, so they make it be available solely to firmware developers.

In a few cases, the answer may be performance -- they have their required use cases tuned appropriately, but there are others that outside developers might try that have not been optimized.

I am sure there are other possible reasons as well.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文