5 ms·

One of the quieter features of Android 9 is that they are reducing the API surface of Android by explicitly black-listing and white-listing various APIs and fie

One of the quieter features of Android 9 is that they are reducing the API surface of Android by explicitly black-listing and white-listing various APIs and fields that previously required reflection to access. None of these APIs were documented, but none of them were explicitly "off limits" before Android P. 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.

the_duke 8y ago
undocumented => documented
- mmastrac 8y ago
  Thanks, fixed my typo.
makmanalp 8y ago
> That suggests that the life of Java as Android's primary language might be really coming to an end 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?
pjmlp 8y ago
Apparently you haven't been paying attention, declaring off limits APIs started with Android Nougat for NDK developers. 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.
- Avamander 8y ago
  > Because Linux APIs were never really intended to be called by NDK developers 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.
  - nine_k 8y ago
    Would you please offer an example of such an app and its outstanding features?
    - Avamander 8y ago
      I wouldn't say "outstanding", I'd say original. For example the app that mapped the Samsung Bixby button to something else, Greenify, Island and Helium. There are others, but these came to my mind first.
- kllrnohj 8y ago
  > Because Linux APIs were never really intended to be called by NDK developers, only the POSIX subset and Android public native APIs. 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.
  - pjmlp 8y ago
    You can try to do it, but good luck guaranteeing that your APK doesn't crash and burn across Android OEMs and people want to still give you money. These are the only APIs devs are officially allowed to touch. https://developer.android.com/ndk/guides/stable_apis https://developer.android.com/ndk/guides/stable_apis Anything else is "works on my phone" kind of thing.
    - kllrnohj 8y ago
      No, that's just wrong. 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.cc https://cs.chromium.org/chromium/src/base/os_compat_android....
jmgao 8y ago
That's a bizarre conclusion to come to. The real motivation is that if you know apps are reflecting into your internal implementation details, and you want to make a change, you're stuck with a bunch of bad choices. 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.
- solarkraft 8y ago
  Break the apps. Undocumented APIs can not be relied on. Of course it's a shame they were available/undocumented in the first place, but at least they are finally fixing this.
- nunez 8y ago
  Dumb question: isn’t this what the Google Play submission process is for?
  - pjmlp 8y ago
    Yes, the problem is that many use private APIs to get around bugs that never get fixed, or even if they do, never reach customer devices. Google is promising that now things will be different, take it with the usual skepticism.
on_and_off 8y ago
I don't see how you come to this conclusion. 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.

the_duke 8y ago

undocumented => documented

mmastrac 8y ago
Thanks, fixed my typo.

makmanalp 8y ago

> That suggests that the life of Java as Android's primary language might be really coming to an end 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?

pjmlp 8y ago

Apparently you haven't been paying attention, declaring off limits APIs started with Android Nougat for NDK developers. 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.

Avamander 8y ago
> Because Linux APIs were never really intended to be called by NDK developers 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.
- nine_k 8y ago
  Would you please offer an example of such an app and its outstanding features?
  - Avamander 8y ago
    I wouldn't say "outstanding", I'd say original. For example the app that mapped the Samsung Bixby button to something else, Greenify, Island and Helium. There are others, but these came to my mind first.
kllrnohj 8y ago
> Because Linux APIs were never really intended to be called by NDK developers, only the POSIX subset and Android public native APIs. 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.
- pjmlp 8y ago
  You can try to do it, but good luck guaranteeing that your APK doesn't crash and burn across Android OEMs and people want to still give you money. These are the only APIs devs are officially allowed to touch. https://developer.android.com/ndk/guides/stable_apis https://developer.android.com/ndk/guides/stable_apis Anything else is "works on my phone" kind of thing.
  - kllrnohj 8y ago
    No, that's just wrong. 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.cc https://cs.chromium.org/chromium/src/base/os_compat_android....

jmgao 8y ago

That's a bizarre conclusion to come to. The real motivation is that if you know apps are reflecting into your internal implementation details, and you want to make a change, you're stuck with a bunch of bad choices. 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.

solarkraft 8y ago
Break the apps. Undocumented APIs can not be relied on. Of course it's a shame they were available/undocumented in the first place, but at least they are finally fixing this.
nunez 8y ago
Dumb question: isn’t this what the Google Play submission process is for?
- pjmlp 8y ago
  Yes, the problem is that many use private APIs to get around bugs that never get fixed, or even if they do, never reach customer devices. Google is promising that now things will be different, take it with the usual skepticism.

on_and_off 8y ago

I don't see how you come to this conclusion. 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.