8000 [BUG?]: symbol visibility for different api levels. · Issue #2132 · android/ndk · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

[BUG?]: symbol visibility for different api levels. #2132

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
1 task done
twaik opened this issue Mar 10, 2025 · 5 comments
Open
1 task done

[BUG?]: symbol visibility for different api levels. #2132

twaik opened this issue Mar 10, 2025 · 5 comments
Labels
bug

Comments

@twaik
Copy link
twaik commented Mar 10, 2025 •
edited
Loading

Description

AConfiguration_setScreenRound does not appear in nm -D toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/aarch64-linux-android/28/libandroid.so but not marked with __INTRODUCED_IN.

ANativeWindow_getBuffersDataSpace, ANativeWindow_setBuffersDataSpace and ANativeWindow_setBuffersTransform have opposite problem. They appear with __INTRODUCED_IN(28) in header but do not appear in nm -D .../28/libandroid.so.

Not sure if it is a bug or a documentation problem but probably it should be fixed.

I am using a supported NDK

  • I have checked and the NDK I'm using is currently supported

Affected versions

r27
@twaik twaik added the bug label Mar 10, 2025
@twaik
Copy link
Author
twaik commented Mar 10, 2025 •
edited
Loading

I did not check all api levels, most likely there are more problems like this.
Probably you can create some automatic test which will catch this thingy automatically.

@twaik
Copy link
Author
twaik commented Mar 10, 2025

Also AHardwareBuffer_getNativeHandle appears in nm -D .../28/libandroid.so despite being VNDK-specific API. Probably it should be removed from the lib.

@DanAlbert
Copy link
Member

I'm not really the person that can answer any of these questions. Only the API authors can say whether these are mistakes or intentional. Not all native APIs are for the NDK. I've started asking around.

Probably you can create some automatic test which will catch this thingy automatically.

No, because there's no way for the test to know what's supposed to be API and what isn't. "The list of APIs covered by CTS" is supposed to be the answer, but for older APIs where we were less strict about requiring all NDK APIs to be covered by CTS, sometimes tests were skipped and then these problems happen.

@github-project-automation github-project-automation bot moved this to Unconfirmed in NDK r30 Mar 11, 2025
@DanAlbert
Copy link
Member

There are some comments in the headers which group some APIs as VNDK only, and some of the commit messages also give some insight. It'll take a while to pick them all apart, but there's definitely at least one thing to fix here.

@twaik
Copy link
Author
twaik commented Apr 10, 2025

No, because there's no way for the test to know what's supposed to be API and what isn't. "The list of APIs covered by CTS" is supposed to be the answer, but for older APIs where we were less strict about requiring all NDK APIs to be covered by CTS, sometimes tests were skipped and then these problems happen.

At least you can

  1. Pull AVD images from Google servers, unpack system partition and check symbol presence with regular nm.
  2. Pull git repositories of Android and check related headers for symbols presence.

I’m not sure if it’s worth the trouble, but at least it will let us avoid weird linking issues and behavior that contradicts the documentation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
NDK r30
Status: Unconfirmed
Milestone
No milestone
Development

No branches or pull requests
2 participants
@DanAlbert @twaik
0