I just noticed this on the web page: > Android is based on Linux kernel, but sadly and unexplicably, Android > userspace > is not Unix-friendly:
I'm working on that. In fact I'm giving a talk "Building Android under Android" at Texas LinuxFest next month: http://2016.texaslinuxfest.org/node/94 I've been working on the problem since 2013, as I explained in this CELF talk: outline: http://landley.net/talks/celf-2013.txt video: http://youtu.be/SGmtP5Lg_t0 And a follow-up in 2015: outline: http://landley.net/talks/celf-2015.txt video: https://www.youtube.com/watch?v=04XwAbtPmAg And yes, my code is going upstream into Android. Toybox became the default command line implementation of Android back in 2015 (Android M and up, see https://lwn.net/Articles/629362/), and Elliott Hughes (the toolbox and bionic maintainer) has now replaced most of toolbox with toybox. (He's working on switching over "top" at the moment, it's fiddly because top -b is used in the android bug report script and everything they do is threaded.) Elliott's also fluffed out bionic a lot so it provides things toybox needs. (You can install musl alongside if you need to, but they're never removing bionic due to strong backwards compatibility requirements.) My goal is to make Android a self-hosting development environment, so that what AOSP can build is capable of building AOSP. Whether vendor Android systems will be able to do this out of the box or require you to install stuff from the google store is up to the vendors. (Right now you need https://play.google.com/store/apps/details?id=jackpal.androidterm&hl=en just to get a terminal emulator, even thought that terminal emulator code comes from AOSP. It's just not selected in the default config.) Once I get the command line finished, they can add clang+llvm (already an AOSP build option, and the LLVM part is used on the target for JVM optimization) and fluff out any missing bits of bionic. There's cleanup work to close the circle: for example I need to write a read-only git downloader capable of powering repo. (Android's no GPL in userspace policy means I need new implementations of any GPL build tool. AOSP already moved its own build system from gnu make to something called "ninja", but I'll probably wind up adding a "make" to toybox after 1.0 anyway.) > in many cases, things are done differently than in "usual" Unix systems. > For example, there is no /bin directory (and therefore ubiquitous #!/bin/sh > scripts won't work). Instead, there is /system/bin. I've poked Elliott about the idea of "development containers" where you have a chroot that's more posixy. It would probably be based on containers, using the UID namespace to delegated a set of UIDs to the container that it can remap as root and such. The problem is, Android's security model predates containers, so intead they sprayed the system down with SELinux and made every android app run under its own UID. Last I checked (when N was still in development, before the O merge window opened up) there was no mechanism for an app to request multiple UIDs (this would need a contiguious range to remap), and of course nothing was using containers yet so there wasn't cgroups management infrastructure and so on yet. I'm busy going through http://landley.net/toybox/roadmap.html and trying to get to 1.0. Only AFTER I ship 1.0 do I worry about the above containers stuff and about dismantling the AOSP build so I can do a "bootstrap-aosp.hdc" build control image under aboriginal linux the way I did bootstrap-lfs.hdc for Linux From Scratch (that's how I get an exact list of what the dependencies _are_ because that system has _nothing_ I didn't explicitly provide)... But yes, there are plans. I have compared notes on these plans with the relevant Google engineers, who let me know where the problems were so I could adjust. That's not the same as a firm commitment for the future to look like this, but there is at least a path forward, and a way for code to go upstream into AOSP. https://github.com/landley/toybox/blob/master/README#L165 > I have a Samsung Galaxy Tab S (SM-T700 model) and I made it compile Busybox > as follows: http://www.samsung.com/us/support/owners/product/SM-T700NZWAXAR Android 4.4 Kit Kat. I.E. Android K, before L, M, and N. Um... Good luck? Only those last 2 releases have toybox in them, and the one in N has a lot more commands (and a lot of bugfixes since) than the one in M. Hmmm, this says newer versions are running L and you can do an aftermarket upgrade to the AOSP M image: http://techbeasts.com/android-60-marshmallow-galaxy-tab-s-84-aosp/ So that's something? Rummage rummage... Ah, N isn't _out_ yet. It's just frozen. So they already forked off from AOSP and are in bugfix-only mode, which is why from my perspective I'm going "didn't that happen a couple months ago already...?" http://techbeasts.com/android-60-marshmallow-galaxy-tab-s-84-aosp/ (My nexus 5 won't run it until cyanogenmod gets around to shoehorning it on, so I haven't been paying close attention to the vendor versions recently...) > "Rooted" the tablet (acquired root access). This step is device-specific. I'm trying to replace this step with a posix build container, but am open to suggestions for better approaches. On the one hand, Android N is getting multi-window stuff because everybody knows android workstations are coming. (You can add a monitor and keyboard/mouse via USB or bluetooth/chromecast today.) But nobody likes the idea of a warhol worm amongst a billion unadministered broadband-connected unix systems with gigahertz processors and gigs of ram and storage that everybody seems to do their banking through and even wants to turn into near-field payment systems for some reason. The Android guys are REALLY paranoid about security. And post-snowden, the "evil butler" scenario is on everybody's minds where somebody gets your phone for half an hour and undetectably rootkits the thing with spyware, that's why all this bootloader key signing and un-disablable "YOU ARE NOT RUNNING A STOCK IMAGE, PRESS BUTTON TO ACKNOWLEDGE THIS BEORE CONTINUING" nonsense happened. It's not corporate greed, you can thank the darn NSA for screwing that one up for everybody. How you let developers reimage their phones without letting the NSA reimage everyone's phones is an INTERESTING QUESTION, isn't it? (I can point people at ELC talks on that if you're interested; not my area.) > Installed the SuperSU application. > Installed the Termux application - it provides a small repository of > essential tools: gcc-based toolchain, git, ncurses, etc. Sigh, am I going to have to implement an ncurses variant for a self-hosting AOSP build? No, it it looks like it's MIT licensed and staying that way: http://invisible-island.net/ncurses/ncurses.faq.html#relicensed > Ran its terminal, installed packages I needed, pulled Busybox git tree. > Created a /bin symlink to /system/bin, to make #!/bin/sh scripts work > (the build fails otherwise). > Now the usual "make defconfig", "make menuconfig", "make" work. I note that a todo item I have for toybox 1.0 is writing a new menuconfig implementation: https://github.com/landley/toybox/blob/master/kconfig/README And that one should use ansi escapes, not curses. (Like the current toybox top and hexedit implementations already do.) That said, "make defconfig" shouldn't have a curses requirement, and if defconfig is still the maximum sane configuration... (Something I did in the most recent toybox release was add "make sed ls cat" targets, which builds the standalone version of each. There's a "make list" that shows the commands, and "make list_pending" that shows the commands that aren't yet ready to be enabled in defconfig.) > Some parts won't compile (not all kernel headers are present, > libc API different or incomplete, etc). The maximal config which did > compile is now in the git tree, in configs/android_502_defconfig. > The toolchain provided by Termux is based on Android's Bionic libc > and Bionic has some design problems. An annoying one is that off_t > is 32-bit, I believe Elliott fixed that last year, because it broke toybox sed? http://lists.landley.net/pipermail/toybox-landley.net/2015-September/004415.html > struct_stat::st_size is not off_t (this violates standard expectations), > therefore CONFIG_LFS=y does not build, and CONFIG_LFS=n builds with > warnings (printf'ing st->st_size with wrong specifier). Try Android N (or current AOSP), I'm pretty sure this got fixed? (At least Toybox works fine. They test it regularly. But we don't have a CONFIG_LFS, it's just always LFS, because it's 2016.) The Android Open Source Project is the upstream Android build, which vendors then snapshot and fork. If it goes upstream into AOSP, it _is_ "in Android". It just may not be in vendor versions for a while. (I believe N has frozen and the merge window is open for Android O.) Rob _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
