Profile

Cover photo
Elliott Hughes
Works at Google
Lives in California, USA
674 followers|171,078 views
AboutPostsPhotosVideos

Stream

Elliott Hughes

Shared publicly  - 
 
I recorded an episode of the confusingly named "ADB" podcast a few weeks ago. For once, this episode actually talks about the real adb. The NDK too. It's up now:

http://androidbackstage.blogspot.com/2016/07/episode-53-adb-on-adb.html

Being a manager and British, I always feel awkward promoting the work of others; worried that it looks like I'm taking credit. I did a reasonable job here, I think, except for the fact that I didn't mention Dan Albert's work on the NDK. It turns out that in a regular conversation it's easy to credit folks who worked on specific pieces -- you just mention their name when that piece comes up -- but it's actually hard to credit the guy who does everything. No small piece seems like the right time to credit them, and the whole never really comes up because it's the topic of the discussion.

Luckily, anyone who's been filing NDK bugs (https://github.com/android-ndk/ndk/issues) knows who's fixing them! But for those of you who haven't even been hitting any bugs lately, you have Dan Albert to thank...

Oh, and if you're the guy who first talked to me about toybox at the Linux Plumber's Conference in Germany a couple of years ago, my apologies for not knowing your name!
8
Add a comment...

Elliott Hughes

Shared publicly  - 
17
5
Add a comment...

Elliott Hughes

Shared publicly  - 
 
The final release of NDK r12 was released yesterday.

Get it here: https://github.com/android-ndk/ndk/wiki

The major change since beta2 is the addition of the headers/libraries for the new NDK camera APIs in N.

Here's a recap of what I called out in beta2 relative to r11:

__thread should be fully working clang now (r11 was missing one patch that was upstreamed but not back in the NDK). Note though that support for __thread variables with destructors requires that your code is running on API level 23+ (but that's true of GCC too).

There's a Python make-standalone-toolchain implementation (which should be especially beneficial to Windows users), and the old shell script will be removed in r13.

r13 will also make clang the default unless you're explicitly requesting GCC, so for those who think "if they were serious about switching to clang, they'd make it the default", the platform already switched the default (in N) and the NDK will switch soon. Procrastinate no longer! If you have bugs keeping you from switching to clang, get them filed.

Full change log here: https://github.com/android-ndk/ndk/wiki/Changelog-r12
10
1
Add a comment...

Elliott Hughes

Shared publicly  - 
 
Korean 2-year old Lee Da-Eul's response to a 1980s cassette recorder: "YouTube!".

I guess we're living in the future...

https://youtu.be/9jTPWwVMuqs?t=1h25m15s
1
Add a comment...

Elliott Hughes

Shared publicly  - 
 
I thought Dave Burke was pretty clear, but Android Police at least misunderstood A/B updates...

"This new feature will be similar to how Chrome handles its updates. In this case, the older version of Android N will be able to seamlessly switch into the new version, separate from the rest of the phone's data. That means all those "Android is upgrading" prompts after system updates will be gone.

All of this is due to the new JIT compiler, which speeds up the update process for Android N. It should also lead to 75% faster app installation. Also, the amount of installation storage space for Android N apps will be 50% less than before."

No, this isn't about the JIT. It's the fact that devices can now have two system images, A and B. That means you don't have to reboot into the recovery image to apply an OTA. If you're running A, you can apply the OTA to [currently unused] B, and then when that's done, flip a (software) switch so the bootloader knows that B is now the system image to boot into. And then on your next update, B is running so you can safely update [currently unused] A while running B.

But this requires two system partitions.

(Your data is already stored on a separate /data partition that isn't mounted by the recovery image, and thus can't be touched by an OTA even if there were a reason to do so.)

The JIT is mostly unrelated to A/B. I think the confusion is between "upgrade" in the sense of OTA and "upgrade" in the sense of "Optimizing app m of n...", and Dave Burke talked about both. Having a JIT does mean it's no longer necessary to have "optimized" (aka "AOT compiled") an app before you can run it, which means it's no longer necessary to suffer that horrible dialog. If you think you have it bad, Google engineers see it every day when they take the nightly build :-)

Ars Technica had a much better article, with which I can find no fault: http://arstechnica.com/gadgets/2016/05/android-n-borrows-chrome-os-code-for-seamless-update-installation/

(The "same code, in some places" that Dave Burke refers to Android and ChromeOS sharing is in AOSP under system/update_engine/, if you're curious. It's also being used by Brillo right now.)
We go on a deep dive into Android's new Chrome OS-inspired partition system.
36
4
Michał Z.'s profile photoElliott Hughes's profile photoArtem Russakovskii's profile photo
20 comments
 
+Elliott Hughes Great, thanks for explaining further. So what happens when the /data storage is low in the initial implementation that doesn't use the online install procedure yet?
Add a comment...

Elliott Hughes

Shared publicly  - 
 
What's new in Android N libc?

With Android N developer preview out today, now's a good time for those of you who're interested in lower-level details than emoji design to hear what the native tools/libraries team has been up to. Today I'll run down the highlights of the platform libc changes...

New pthread barriers and spinlocks: pthread_barrierattr_destroy/pthread_barrierattr_getpshared/pthread_barrierattr_init/pthread_barrierattr_setpshared/pthread_barrier_destroy/pthread_barrier_init/pthread_barrier_wait, pthread_spin_destroy/pthread_spin_init/pthread_spin_lock/pthread_spin_trylock/pthread_spin_unlock.

New networking functionality: getifaddrs/freeifaddrs/if_nameindex/if_freenameindex.

New I/O functionality: fileno_unlocked, lockf/lockf64, preadv/preadv64/pwritev/pwritev64,, scandirat/scandirat64.

New misc functionality: getgrgid_r/getgrnam_r, strchrnul.

Finally finished _FILE_OFFSET_BITS=64 support: fgetpos64/fseeko64/fsetpos64/ftello64/funopen64.

Security: _FORTIFY_SOURCE for fread/fwrite/getcwd/pwrite/write (from Daniel Micay of Copperhead). setjmp/longjmp jmp_buf cookies. -fstack-protector-strong on for entire platform.

Numerous header file additions/improvements.

Linux kernel headers updated to 4.4.

Finally removed dlmalloc: new svelte jemalloc configuration gives you jemalloc performance with a dlmalloc footprint.

New debug malloc implementation (bionic/libc/malloc_debug; README.md coming soon, source.android.com documentation coming after that).

We also worked on tsan support (though you'll need a newer clang than the prebuilt that will ship with N).
45
5
Add a comment...
Have him in circles
674 people
Laura Norvig's profile photo
Michael Bailey's profile photo
Dennis Drewery's profile photo
Graham Sysko's profile photo
Hojin Ghim's profile photo
Aladdin Tarshan's profile photo
Ani Ravi's profile photo
Roshan Lal's profile photo
Michael Engineered's profile photo

Elliott Hughes

Shared publicly  - 
 
When someone like Satya Nadella (MS CEO) who really ought to know better says something that sounds like the kind of ignorant nonsense you'd usually hear from an arts student ("We humans have creativity, empathy, emotion, physicality, and insight that can then be mixed with powerful A.I. computation..." in his recent Slate article) it's hard not to wonder whether:

1. he's really not thought about this at all (nor ever read anything from anyone who has thought about this).
2. he harbors crypto-religious sentiments (humans having souls that machines can never have) that he's unwilling to state explicitly.
3. he's trying to calm the masses by pretending to them that they are actually unique and beautiful snowflakes and that mummy and daddy will always love them no matter what.
4. he's being deliberately misleading, not actually saying that machines can't have these things but leading us to infer them.

If the Brexit/Trump supporters are unhappy now, they're really going to hate the next 50/100 years. At least fear and hatred of the machines is likely to help humans get over their fear and hatred of each other.

In the meantime, http://smbc-comics.com/ regularly has web comics on these themes far more insightful than anything in Nadella's worthless article.
9
Luke Sleeman's profile photo
 
+1 for SMBC - for a random web comic, they tend to come up with some really interesting and amusing stuff.

As for if humans have something ineffably different from machine AI - I doubt it. We already know that human level intelligence can exist - albeit running on biological hardware. I see nothing fundamental to stop similar level intelligences being created ... though of course at the moment there are enormous practical problems: Namely, we don't know how to do it :-)
Add a comment...

Elliott Hughes

Shared publicly  - 
 
This week's blog post is a superset of last week's, covering all the dynamic linker changes NDK users need to be aware of:

http://android-developers.blogspot.com/2016/06/android-changes-for-ndk-developers.html
8
1
Add a comment...

Elliott Hughes

Shared publicly  - 
 
Updates today to "Debugging Native Android Platform Code" go into a bit more detail about debuggerd output/tombstones.

I've been collecting examples of the most common kinds of crashes for a while now, but I probably need to switch to fake crashes before we put that on stuff on the web too :-)

https://source.android.com/devices/tech/debug/index.html
11
2
Satish Patel's profile photo
 
+1 good compliation.
Add a comment...

Elliott Hughes

Shared publicly  - 
 
Some Android news that was drowned out by I/O: NDK r12beta2 was released during I/O.

Get it here: https://github.com/android-ndk/ndk/wiki

__thread should be fully working clang now (r11 was missing one patch that was upstreamed but not back in the NDK). Note though that support for __thread variables with destructors requires that your code is running on API level 23+ (but that's true of GCC too).

There's a Python make-standalone-toolchain implementation (which should be especially beneficial to Windows users), and the old shell script will be removed in r13.

r13 will also make clang the default unless you're explicitly requesting GCC, so for those who think "if they were serious about switching to clang, they'd make it the default", the platform already switched the default (in N) and the NDK will switch soon. Procrastinate no longer! If you have bugs keeping you from switching to clang, get them filed.

Full change log here: https://github.com/android-ndk/ndk/wiki/Changelog-r12-beta2
11
Add a comment...

Elliott Hughes

Shared publicly  - 
 
There was a question on androidpolice's article about the N adb improvements that asked (and I paraphrase because I'm too lazy to find the original again) "can we have a faster fastboot too?".

The main limitation for fastboot performance is the size of the USB writes. Increasing the size of those writes turns out to be a great way to lock up your machine, at least for the Linux 3.13 kernels on the z840s we use internally. The Mac USB implementation is already flaky enough to not be recommended.

As for Windows (which is what most external folks care about)... sadly all internal Windows testing is done in a VM, and Spencer Low (source of most of the Windows-specific adb improvements) doesn't use fastboot. The Windows bulk transfer chunk size is already a lot larger than Linux/Mac OS --- it's 1MiB. If you're prepared to cross-compile your own Windows fastboot binary, just change one line in usb_windows.cpp to increase this:

  #define MAX_USBFS_BULK_SIZE (1024 * 1024)

Feel free to let us know whether larger sizes are helpful on Windows, preferably with before/after numbers.
26
3
Add a comment...

Elliott Hughes

Shared publicly  - 
 
What's new in Android N adb/shell?

adb push/pull/sync much faster. (AOSP N9 full /system sync down from 60s to 20s.) Now with better progress feedback showing percentage complete.

adb push/pull interpret command-line arguments more like scp.

adb shell: returns remote process’ exit status, distinguishes stdout/stderr, passes through stdin (so you can pipe into a remote process), passes window size and terminal type (and updates window size), >1024 shell command length. These features all require a new adbd, so even with a new adb they’ll only work when talking to new devices. (Most of this work was done by the Brillo team.)

Windows support greatly improved (99% of this work done by external contributor Spencer Low).

Increased stability for automated testing.

Helpful diagnostics for adb/fastboot Linux USB permissions problems.

Numerous command-line tool improvements/bug fixes. In particular, ls(1) is now the much more full-featured toybox ls. Unlike in M, sed(1) now works fine.
114
26
Joshua J. Drake's profile photoMark Davis's profile photoKrzysztof Jaworski's profile photo
4 comments
 
nic nie rozumiem , bardzo słabe tłumaczenie
 ·  Translate
Add a comment...
People
Have him in circles
674 people
Laura Norvig's profile photo
Michael Bailey's profile photo
Dennis Drewery's profile photo
Graham Sysko's profile photo
Hojin Ghim's profile photo
Aladdin Tarshan's profile photo
Ani Ravi's profile photo
Roshan Lal's profile photo
Michael Engineered's profile photo
Places
Map of the places this user has livedMap of the places this user has livedMap of the places this user has lived
Currently
California, USA
Previously
England - Switzerland - Germany
Work
Occupation
Software Engineer
Employment
  • Google
    Software Engineer, present
  • BlueArc
  • GeneData
Basic Information
Gender
Male
Relationship
Married