[Toybox] Fun with the android NDK.

[enh]

On Sat, Sep 8, 2018 at 12:56 PM Rob Landley <rob at landley.net> wrote:
>
> On 09/06/2018 04:35 PM, enh wrote:
> >> I hit that conflict too. The problem is being ok to use with the NDK _now_
> >> doesn't mean it won't add its own later and then hit the same conflict. (That's
> >> why I put the local copy of the structucture definition under a new name in my
> >> patch; ugly but avoids the conflict.)
> >
> > no need to worry. when i added the struct, i added the corresponding
> > unit test that it's visible when you include <netinet/ip_icmp.h>, so
> > we can't regress the user-visible part even if the exact location of
> > the struct changes.
>
> Ping seems to work as-is in the new NDK version, so yay.
>
> >> Except support for 32 bit's being dropped at some point and I dunno the schedule
> >> of that in the ndk... hmmm. Is there a newsletter on this sort of thing? An
> >> android version of lwn.net maybe?
> >
> > roadmap: https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md
> >
> > release notes (which tend to include forward-looking announcements):
> > https://developer.android.com/ndk/downloads/revision_history
>
> Oh good. I should link those from the toybox web page somewhere... Ah, under
> android roadmap makes sense.
>
> I see the plan to move to compiler-rt: Are you familiar with Rich Pennington's
> http://ellcc.org ? He got a toolchain with no gnu components working a few years
> ago, including compiler-rt. (He works down the hall from me at my current
> contract, we keep meaning to sit down some evening and work out an update of
> ellcc that would let me use his toolchain in my
> https://github.com/landley/mkroot project but we've both been too busy so far...)

oh, it basically works, but there are lots of missing pieces and
corner cases (that differ between architectures). the NDK tends to hit
more of these than the platform, because we have enough control over
the platform code to just work around problems when we need to.

> > but, no, 32-bit isn't going anywhere any time soon. we *are* insisting
> > that folks have a 64-bit version of any 32-bit app so that at some
> > point it'll be possible to have a 64-bit-only device, but i assume
> > even that will only be another step in the slow decline of 32-bit.
>
> 32 bit's alive and well in the embedded space, and x32 remains interesting on 64
> bit systems, but there's only 20 years until y2038...

sadly i'm not sure that will be sufficient in general:
http://man7.org/linux/man-pages/man2/statx.2.html

this (or fixing time_t) would be ABI breaks for Android, though, so i
assume that 32-bit Android will go away, even if 32-bit Linux lives
on.

> (Embedded's weird: I'm told there are more nommu processors than with-mmu
> processors in the world, which is about like saying there are more bacterial
> cells than non-bacterial cells in the world. Embedded Linux is about like the
> "insects" layer of the ecosystem, which is still flipping enormous.)
>
> > (and remember that the NDK effectively has to worry about ~5-year old
> > devices, so even if you weren't allowed to ship a 32-bit P device
>
> I'm all for it. Toybox's historical horizon for working with old toolchains and
> kernels and such is 7 years. :)
>
> > [which isn't true --- you totally can] it would still be ~2023 before
> > we could consider dropping 32-bit from the NDK [assuming that device
> > lifespan stays roughly where it currently is].)
>
> Good to know. My personal experience has been... different.
>
> Wikipedia[citation needed] says the Nexus 5 was introduced October 31, 2013, my
> blog says I got mine for christmas 2014, and it got its last update October
> 2016. I.E. my phone was "supported" for just under 2 years after I bought it,
> it's been a zombie for a couple years already, and 5 years from the hardware's
> launch date isn't 'till halloween.

my point is that even if your Nexus 5 hasn't had an OS update in a
couple of years, it can still download new apps. NDK r17 still
supports targeting >= ICS from 2011, which is several years older than
the oldest OS release that runs on Nexus 5.

when i say "device lifespan" i mean "years before users stop
installing apps on it, and app developers stop caring about it", not
"years it gets OS updates".

(fwiw, Nexus 5 got KitKat, Lollipop, and Marshmallow.)

the Android P version of the CDD
(https://source.android.com/compatibility/android-cdd) still allows
shipping new 32-bit devices. so the countdown timer to the NDK
dropping 32-bit support hasn't even started yet.

> *shrug* I'm still using it (three screen replacements and a new battery later).
> It's remotely exploitable at least 3 different ways I know of
> (https://www.krackattacks.com/
> https://www.theverge.com/2017/9/12/16294904/bluetooth-hack-exploit-android-linux-blueborne
> https://youtu.be/TDk2RId8LFo ), still running Marshmallow, and half the time I
> want to use the camera I have to reboot the phone first. But there's no
> guarantee T-mobile would support anything I move _to_ any longer than it did
> this one, is there?
>
> Still, it's nice Google's better about this than the phone companies. (I keep
> meaning to put Oreo on it. I unlocked the bootloader last year when I disabled
> the "Google App" in the because online insructions said that stopped flaky
> earbud connections from popping up Google Voice every 30 seconds, and the
> resulting boot loop required a factory reset to undo, and as long as the thing
> was wiped _anyway_... only took 3 days. But I haven't tried to put an
> experimental build on it because I use it as a phone; my netbook runs a stock
> ubuntu LTS for the same reason. And every other device I've gotten to experiment
> with, I _haven't_ managed to get the bootloader unlocked yet. Mostly due to lack
> of deadline pressure I expect...)
>
> Rob