ndk
ndk copied to clipboard
android
[FR] improve bad diagnostic for `__REMOVED_IN` on `ALooper_pollAll`
Description
error: 'ALooper_pollAll' is unavailable: obsoleted in Android 1
45 | if (ALooper_pollAll(IsVulkanReady() ? 1 : 0, nullptr,
| ^
usr/include/android/looper.h:216:5: note: 'ALooper_pollAll' has been explicitly marked unavailable here
216 | int ALooper_pollAll(int timeoutMillis, int* outFd, int* outEvents, void** outData) __REMOVED_IN(1);
| ^
It's been marked obsolete because the implementation is racy and can't be called safely, but ALooper_pollOnce can be called in a loop for the same effect, and is available for all supported OS versions.
The diagnostic is next to useless though, and should be expanded to include that explanation.
I've explained the OS bug in another thread to not bog down this bug (which is about an unclear diagnostic, not a missing API): https://github.com/android/ndk/discussions/2020.
is plain old __attribute__((__deprecated__(("use foo instead")))) a better choice then, since it includes a user-provided diagnostic?
__attribute__((availability)) supports that too. We don't expose that in __REMOVED_IN() though, and that's the fix we need.
oh, yeah, that seems like a bug in __REMOVED_IN() --- i vote we require an explanation...
Don't know why I didn't think of that, or why we didn't do that in the first place :) +1
Status? SDL will not compile for android because of this bug
this bug won't fix any builds --- this bug will just give you a compiler diagnostic explaining that you need to switch from ALooper_pollAll() to ALooper_pollOnce().
but, yes, it looks like even SDL 3.0 relies on ALooper_pollAll(): https://github.com/libsdl-org/SDL/blob/12b6c17575a4b24539b7d17625232fff899c90cf/src/sensor/android/SDL_androidsensor.c#L73
It also uses ALooper_wake, so this is not a false positive. That's a bug in SDL.
EDIT: It may not be. The bug happens if you use pollAll in combination with both events signaled by callbacks and those signaled by wait. There's definitely a wait in that code. Whether there's a callback or not is not depends on how the sensor API is implemented in the OS, I think.
Okay, looking even more closely, it's not just in combination with callbacks, and wake and any other event, so yes, that probably does have the bug. See the discussion post I added to the OP for more info.