That suggests that the life of Java as Android's primary language might be really coming to an end, even though Android is very much a platform built on Java/C++ at its core.
1. Break the apps.
Users tend to get annoyed when they upgrade the OS and their apps stop working.
2. Maintain a compatibility shim.
Depending on what the change you're making does, this might not even be possible. Assuming that it is possible, how do you know what needs a shim and what behavior is actually expected?
3. Give up and do something else instead.
Things get worse if you consider that OEMs may want to modify implementations as well, so you'll end up with apps that work, except on some devices. There's no sensible way to prevent app breakage when there are apps depending on your internal (and explicitly private) API; the solution is enforcement.
Of course it's a shame they were available/undocumented in the first place, but at least they are finally fixing this.
Google is promising that now things will be different, take it with the usual skepticism.
Huh - how did you get to this conclusion? What would be the alternative? Do you mean Java was essentially "better" because it had access to all the undocumented APIs while other languages didn't?
Because Linux APIs were never really intended to be called by NDK developers, only the POSIX subset and Android public native APIs.
Likewise with Java, which is only a subset of proper Java.
In any case, it might relate more to an eventual future support of Java 9 module system, where private really means private, than anything else.
But pretty much all the "unintended" uses of Android APIs (undocumented or not) have been the most original and best-integrating apps I've seen. It's a pity.
That's not even slightly true? Android doesn't pretend to be anything but a Linux system, with all the Linux details shining through in all their glory.
There is a seccomp policy that blacklists some syscalls, but it's only 17 out of 271 for ARM64 and it's things like setuid or reboot which you won't have permission to do anyway. Other than that you're completely free to go nuts with raw syscalls, you're in no way, shape, or form stuck going through a POSIX layer.
These are the only APIs devs are officially allowed to touch.
https://developer.android.com/ndk/guides/stable_apis
Anything else is "works on my phone" kind of thing.
It becomes your responsibility to ensure your syscalls match and are available on the kernel you're actually running on which you may be confusing with "not allowed to use".
And very nearly all of the time this is a complete waste of everyone's time since the syscalls are a direct mirror of what's in libc anyway just with libc doing the compatibility for you.
But just to really prove that you can absolutely syscall on Android, one of the largest, most widely deployed & shipped NDK/SDK apps does it to workaround a missing futimes in bionic: https://cs.chromium.org/chromium/src/base/os_compat_android....
This change is only made because devs used the openness of java in order to access private APIs.
It is ok in some cases, but in others private means private.
Like you would have 'smart' devs manipulating the system resource cache .. even though it is not supposed to be a public API and they can mess up their app very easily if they touch it.
Nothing to do with moving away from Java.