![]() ![]() The following projects are things we intend to do, but have not yet been scheduled into the sections above. As such they will not appear in any specific release, but are noted here to show where the team's time is being spent. The samples, documentation, etc are all NDK work but are separate from the NDK package. Note that some of these projects do not actually affect the contents of the NDK package. The following projects are listed in order of their current priority. Wrappers for NDK APIs would also be able to, in some cases, backport support for APIs to older releases. Once that’s done we can start using Jetpack to ship helper libraries like libnativehelper, or C++ wrappers for the platform's C APIs. ![]() We‘re working with the Jetpack team to build the infrastructure needed to start producing C++ Jetpack libraries. We're consolidating all of these in one place (the toolchain) so that all LLVM updates include libc++ updates. We also still have two separate test runners. We still need to update libc++ twice: once for the platform, and once for the NDK. Testing toolsĪdd GTestJNI to Jetpack to allow exposing native tests to AGP as JUnit tests. Port thread sanitizer for use with NDK apps, especially in unit/integration tests. Further backports to r23 are unclear because they may risk destabilizing the release. LLVM was shipped as universal binaries in r23b, and the rest of the tools are expected to move in r24. Migration of all the tools involved in an NDK build to be fat binaries will land over the course of a few releases. Workflow improvements to decrease the costs of regular maintenance.Improving tooling for third-party packages via ndkports:.Working with the Android frameworks teams to get new NDK APIs.Improving the OS (in particular the linker).Improving NDK and Android Gradle Plugin documentation.Most of the team's work is currently focused outside the NDK proper, so while the NDK release notes may seem a bit sparse, there are still plenty of improvements coming for NDK users: If an NDK release doesn’t include a new compiler, or that compiler isn‘t as new as you’d hoped, trust us - you wouldn't want anything newer that we have just yet! Current work The aim is that each NDK will have a new toolchain that‘s as up to date as feasible without sacrificing stability, but we err on the side of stability when we have to make a choice. ![]() We also don't want to perform a full compiler update late in the NDK release cycle for the sake of stability. In the OS, we can work around compiler bugs by changing our code, but for the NDK we want to make compiler updates cause as little disruption as possible. It can take a long time to investigate issues when compiling - or issues that the newer compiler finds in - OS code or OEM code, for all 4 supported architectures, so these updates usually take a few months.Įven then, a new OS toolchain may not be good enough for the NDK. ![]() Android's toolchain team is constantly working on updating to the latest upstream LLVM for the OS. The NDK and the Android OS use the same toolchain. We also maintain GitHub Projects to track the bugs we intend to fix in any given NDK release. Note: For release timing, see our release schedule on our wiki.Įvery NDK release aims to include a new toolchain, new headers, and a new version of libc++. Beyond that, anything written here is what we would like to accomplish in that release assuming things have gone according to plan until then. Things in the upcoming release are fairly certain, and the second release is quite likely. The further the plans are in the future, the less stable they will be. Note: If there‘s anything you want to see done in the NDK, file a bug! Nothing here is set in stone, and if there’s something that we haven‘t thought of that would be of more use, we’d be happy to adjust our plans for that.ĭisclaimer: Everything here is subject to change. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |