-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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.
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
Android 12 | [Bug]: OpenJDK is broken due to tagged pointers #7332
Comments
Maybe try adding The logic for decision has changed in android |
I wrote up why this was happening with Swift on the Swift forums in May: the issue is that Swift sets its own tag in the top byte and that collides with Android's system tagging. Presumably something similar is happening with OpenJDK. |
It appears that hardware support for memory tagging will only roll out with the new ARMv9 CPUs in the next year, but that link does mention "Software support for using MTE is being introduced as part of Android 12." Maybe Android 12 will require software tagging, even though most hardware that is still ARMv8 doesn't natively support it yet, to get everyone to update any software that uses its own tag in the top byte, causing collisions. In our case, that only appears to be these three packages, so not much? |
I just upgraded to Android 12 and have no problem with tagged pointers. Maybe this will only be a requirement for new devices that ship with Android 12 from now on. |
Seems to work fine for me on my s21 ultra running android 12 |
That shipped last year with Android 11 though, right? As I noted above, they're not requiring devices that upgrade to Android 12 to enable MTE, though they may be doing so for new devices that ship with Android 12, like the recently released Pixel 6, for all we know. |
Oh sorry my bad in that case I hope this gets fixed by time I buy a new phone |
I asked and was told that the Android team has decided to reserve the entire top byte on pointers in AArch64 devices, android/ndk#1653, which is apparently being slowly rolled out starting with Android 11. I'm working on a patch for Swift, where the runtime has always set the top bit on pointers to determine whether to reference-count them or not, to account for this Android change. |
Is there any workaround for this at the moment? I'm running Termux on my Galaxy Tab S7, which got updated to Android 12 recently... And I'd really want to run Java on there. |
@MonsterDruide1, was it working fine with Android 11 on your Tab S7 before? |
I updated my tablet about half an hour before trying to use Java, so I'm not sure if it would have worked. The update has been published very recently by Samsung and upgrades to OneUI 4.0, but I'm not even sure anymore whether it had Android 11 or 12 before that specific update. |
OK, was wondering if they switched tagged pointers on with the update... guess we'll never know. It appears that OpenJDK uses its own pointer tags that collides with Android's new memory tagging: I'm unaware of any JDK workaround other than rebuilding Termux yourself with the tagging flag turned off, as mentioned above. |
Okay, but that definitely already is a workaround I can try. Thanks for the quick response, and I'll report on whether it works later! |
No, this doesn't seem to work. I've added |
I notice that you pasted two colons in that flag here, while every other flag uses one? |
Oops, that was just a typo in the comment here. It is properly written with a single colon in Android Studio. Note, I've also tried upgrading the NDK version. There seem to be more issues with lifting the compile, target and minimum SDK to 31, but it's still crashing with them being at |
Also, maybe an important thing: |
Ummm, just curious, which branch of |
I'm using |
I am assuming that it worked because you upgraded an app from an older https://github.com/termux/termux-packages/wiki/Termux-and-Android-10 But if you were to bump version, even login shell would fail, you would need use https://github.com/termux/termux-packages/wiki/Termux-and-Android-10 |
The Did u reinstall apk? For changes in bootstrap to take place, you need to have a fresh install. Installation is only done once.
The whole point of updated flavor branch is so that all binaries exist inside the apk, otherwise execution isn't allowed by android. Welcome to the wannabe-security-android-design. The |
Ohh, wait a second, there is no What would be the right setup here? I'm now trying to remove all the contents of
Yes, I'm uninstalling after every attempt, and I'm doing a full clean rebuild of gradle after each change to either gradle files or bootstrap zips.
Oh. That's bad. Why would they even want to do that? If the developers of some app want to run malicious code, they can surely do that from within the
I didn't really understand a lot of what you said there, I'm not too experienced with Linux... all I can say is that I'm currently building for the simplified, updated gradle file, let's see if it works with that one. def downloadBootstrap(String arch, String expectedChecksum, String version, boolean isPackagesInApk) {
def file = new File(projectDir, "src/main/cpp/bootstrap-" + arch + ".zip");
expandBootstrap(file, expectedChecksum, arch)
return
} |
First you need to ensure you are building the
Yeah, should work.
Pretty much, apks built on dev devices or servers already violate W^X. But yeah, off topic. If you run FYI, for PATH and LD_LIBRARY_PATH, check https://github.com/agnostic-apollo/tudo#path-and-ld_library_path-priorities |
Okay, there are now a LOT more
However, invoking |
It seems like the encoding of |
This comment has been minimized.
This comment has been minimized.
Pointer tag for 0x6f43493930 was truncated, see 'https://source.android.com/devices/tech/debug/tagged-pointers'. Receiving this error after upgrading to Android 12 and using OpenJDK 17 |
a new solutionthe old solutionIf you just want to run java and don't care about performance, you only need to get a 32 bit java installation. Tagged pointers are entirely a 64-bit thing, so 32-bit java is completely unaffected. As a proof of concept, I modified the termux apk, removed the arm64 library and re-signed. After reinstalling the app, I get a pure 32 bit shell. Now I can use java in Android 12. Here's my modified apk, if you're interested: Note that you need to uninstall the original termux to install it, your data will be lost. There is obviously a better way to install it, but it's also more complicated (termux's |
FYI, termux github builds are also supplied as arch specific so no need to modify apk. https://github.com/termux/termux-app/releases/tag/v0.118.0 |
have a hack way to use OpenJDK in Android 12,like this but no need install 32bit Termux,just download 32bit OpenJDK deb file from Termux repo and extract deb file resource,then set JAVA_HOME env, using
|
A complete guide to installing 32-bit java in 64-bit Termux shellFrom: https://hu60.cn/q.php/bbs.topic.102531.html (zhCN)
|
It would be better to wrap the actual |
I don't understand what the problem is, this has been known for over a year and no one has yet decided to create a patch to fix this? |
Feel free to open a PR if you know how to fix it. |
Sure, you can follow those instructions as a workaround (easy to do on affected devices), but a fix would preferably fix the root cause as done for swift. |
One argument for a workaround is that a quick workaround to restore degraded functionality is better than waiting an indefinite amount of time with no functionality for a non-existent proper fix. Is there a strong argument against the workaround? E.g. does it lead to undefined behaviors, cause undue maintenance burden, etc? |
Maybe I can borrow the idea of #7332 (comment) and write a patch. The problem is that I cannot test it on my own because I do not have access to any affected environment. I won't commit it until sufficiently tested by others. |
Please test #10347. Thanks. |
Any more update? Is this issue resolved? |
Seems to be working? Compiled a few small .java files with various standard library imports. Even compiled a trivial Android app to an .apk, installed, and ran. Could use more rigorous testing. |
ohhhh... I get it. After 90 hours of thinking I was fixing java wrong, I came to understand that this still doesnt mean gradle wont fail with same error, for same reason. ..or maybe i dont get it. I probably dont get it. |
If you need OpenJDK in Termux - do not upgrade to Android 12.
Problem description
After upgrading to Android 12, workaround for tagged pointers in package
openjdk-17
is not working anymore.This means we will need to either wait fixes on upstream or fix broken packages manually which may require quite much effort, depending on codebase size.
Other packages known to be affected by issue with tagged pointers:
swift
- swift: some binaries do not work on Android 11 #6261st
from x11-packages - https://github.com/termux/x11-packages/issues/407What steps will reproduce the bug?
pkg upgrade && pkg install openjdk-17
javac
without arguments or attempt to compile something.System information
termux-info:
The text was updated successfully, but these errors were encountered: