ALooper_pollAll is gone, what do I do?

[DanAlbert]

The OS has marked ALooper_pollAll as removed. The definition is still present in libandroid, so existing apps will continue to function (though probably with the bug described below), but apps building with NDK r27 or newer will not be able to call that function.

To explain here since the explanation isn't in the docs yet: ALooper_pollAll will not wake in response to ALooper_wake if it also handles another event at the same time. The exact circumstances where calls to ALooper_pollAll is or isn't a bug aren't the kind of thing we can write a perfectly accurate diagnostic for, but it's unlikely that any non-trivial application that uses pollAll is free of this bug. As such, the API was marked removed, since there is a safe replacement.

The core of the problem is the nuance in https://developer.android.com/ndk/reference/group/looper#alooper_pollonce:

Returns ALOOPER_POLL_WAKE if the poll was awoken using wake() before the timeout expired and no callbacks were invoked and no other file descriptors were ready.

ALOOPER_POLL_WAKE is only returned when ALooper_wake is the only event handled. ALooper_pollAll uses ALooper_pollOnce internally, and only returns when it receives ALOOPER_POLL_WAKE, which is not necessarily returned when ALooper_wake is called.

The fix, aiui, is to call ALooper_pollOnce, and break out of your loop for any of the results, not just ALOOPER_POLL_WAKE, since any other return value might also imply ALOOPER_POLL_WAKE.

[DanAlbert]

See android/ndk-samples#1008 for an example of the fix.

[MarijnS95]

Is it "not safe" just because ALooper_pollAll() may not return even if ALooper_wake() was called, or does this actually cause Undefined Behaviour?

[DanAlbert]

Sorry, I thought I'd already answered in my first comment. There's no UB that I'm aware of. "Cannot be used reliably" would have been a better word choice, I suppose.

I'll send a CL to improve those docs, but in the future please file documentation bugs when you find issues with the documentation. It's not scalable for all of these problems to come to me, especially if they're a forum post and not a bug report. Share links to those bugs here if they seem to get stuck (though it's usually the case that we all just have too much on our plates), but I'm usually not in a position to help with APIs because I rarely know more than what's written in the docs, and the authors don't typically monitor GitHub because that's not where their work is.

I know it's frustrating to try to work out where to file something, but my options are pretty limited for improving that short of closing this GitHub project and moving the NDK bug tracking to Issue Tracker. Every time I've suggested that someone talks me out of it. Aside from that, but best I can do is try to make https://github.com/android/ndk/issues/new/choose clear and redirect you when this is the wrong forum. If there's something that can be done to improve the directions on that landing page, lmk. I just made a few minor adjustments.

The bugs here are, if I've understood correctly:

1. "cannot be used safely" is worded too strongly
2. The docs for ALOOPER_POLL_CALLBACK are out of date

Is that correct?

At risk of sounding disrespectful, I don't think I need to file a framework bug to ask about this "safety" wording if @DanAlbert could respond here directly, unless you were indirectly asked to use that wording and truly are "just the deliver truck"?

No, that's pretty much it. In almost all cases I'm just a middle-man when it comes to the APIs. The way I answer these questions when I do is by asking the API author and then (sometimes badly) parroting them here. In this specific case I know slightly more because I had to go learn this API so I could fix the samples, but that's the exception, not the norm (and even here, that's long enough ago that I'd already forgotten everything I hadn't written down here or in the docs). You'll pretty much always get better answers by talking to the API authors themselves.

It isn't that I don't want to help, it's that I'm not well equipped to help with these kinds of problems (and even when I am, I don't scale very well). The best way I can help is by connecting you with the people that do know the answers, and that's best done by filing bugs.

I could however file one to ask/dispute the choice for completely deprecating this call and making it inaccessible.

This is what I thought you were asking.

[DanAlbert]

Ugh. This would have been somewhat clearer if our doxygen processor wasn't hiding some of the docs from you. This part is in the source but absent from the webpage:

\bug ALooper_pollAll will not wake in response to ALooper_wake calls if it also handles another event at the same time.

https://cs.android.com/android/platform/superproject/main/+/main:frameworks/native/include/android/looper.h;l=221-222;drc=26620a62ebf3dd901f5d33e65c57c98414a11df9

Fixing that kind of thing is actually what I was supposed to be doing today, so I'll add that to my list.

[DanAlbert]

https://r.android.com/3353154

[MarijnS95]

It wasn't my intention to divert from "the real bug reporting tool" to a "forum" here, merely to reply to the announcement initially and that spiraled into this discussion and request for both announcement and documentation rewording :)
(Note that for lots of developers, GitHub is their main place of work and tracking. For us, it's not just "a forum post")

It is definitely possible to keep this repository around while disabling issues and discussions, assuming there are clear enough markings in the README to divert everyone to the real bugtracker:

---

The bugs here are, if I've understood correctly:

1. "cannot be used safely" is worded too strongly
2. The docs for ALOOPER_POLL_CALLBACK are out of date

Is that correct?

I'd argue that the fallout from point 1. would be to reconsider whether the function should have been deprecated and hidden in the first place, even if there's likely nothing we can do about it anymore.

---

Thanks for opening the change so quickly, I'll do my best to review and approve it :)

[DanAlbert]

(Note that for lots of developers, GitHub is their main place of work and tracking. For us, it's not just "a forum post")

I'm referring specifically to GitHub Discussions, which is the forum part of GitHub.

It is definitely possible to keep this repository around while disabling issues and discussions, assuming there are clear enough markings in the README to divert everyone to the real bugtracker:

I don't want to do that though. This is the correct place for NDK toolchain bugs (like you say this is the main place of work for a lot of people, we wanted to meet people where they were), and having a forum is also useful. But when we're the wrong people to be talking to, I am of course going to redirect you to people that can help.

I'd argue that the fallout from point 1. would be to reconsider whether the function should have been deprecated and hidden in the first place, even if there's likely nothing we can do about it anymore.

You're arguing with the wrong people :) If that's what you want, please go file a framework bug on http://b.android.com.