Fixed
Status Update
No update yet.
Comments
uc...@google.com
Hi there,
as pointed out already over at GitHub, I think all that's missing is another switch passed to llvm-rs-cc to emit either 32/64bit code pretty much here:
https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/internal/compiler/RenderScriptProcessor.java#224
Since we depend on RenderScript working with Android NDK for 64bit apps as of today [1], this issue is quite urgent for us.
May I kindly ask to prioritize this bugfix as the actual fix doesn't seem to be too much work?
In principle, we could pass -m32/-m64 to llvm-rs-cc ourselves to generate the correct bytecode. However, this is not feasible when building a release APK as we otherwise will run in all kinds of issues due to wrong checksums etc. We neither want to call aapt2 ourselves to generate an APK (but continue using the Android Gradle plugin), as the actual packaging is quite cumbersome and prone to errors.
Thanks in advance
[1]https://android-developers.googleblog.com/2019/01/get-your-apps-ready-for-64-bit.html
as pointed out already over at GitHub, I think all that's missing is another switch passed to llvm-rs-cc to emit either 32/64bit code pretty much here:
Since we depend on RenderScript working with Android NDK for 64bit apps as of today [1], this issue is quite urgent for us.
May I kindly ask to prioritize this bugfix as the actual fix doesn't seem to be too much work?
In principle, we could pass -m32/-m64 to llvm-rs-cc ourselves to generate the correct bytecode. However, this is not feasible when building a release APK as we otherwise will run in all kinds of issues due to wrong checksums etc. We neither want to call aapt2 ourselves to generate an APK (but continue using the Android Gradle plugin), as the actual packaging is quite cumbersome and prone to errors.
Thanks in advance
[1]
al...@gmail.com
Can you please provide a small project for his, as well as detailed instructions on how to reproduce?
That would help expedite things.
That would help expedite things.
da...@google.com
Hello,
Here is a minimal project that reproduces it. I've added the instructions for reproducing to the README:https://github.com/Dockheas23/renderscript-gradle-64
Thanks a lot
Here is a minimal project that reproduces it. I've added the instructions for reproducing to the README:
Thanks a lot
da...@google.com
Hey,
Thanks for the project!
Unfortunately, I am having trouble compiling in my local machine after it is cleaned.
~/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/sysroot/usr/include/c++/v1/memory:3132: error: undefined reference to 'ScriptC_example::ScriptC_example(android::RSC::sp<android::RSC::RS>)'
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
Can you please fix the issue for AGP 3.6.0-alpha02 and send it back to me?
You can include classpath 'com.android.tools.build:gradle:3.6.0-alpha02' in your build script
Thanks for the project!
Unfortunately, I am having trouble compiling in my local machine after it is cleaned.
~/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/sysroot/usr/include/c++/v1/memory:3132: error: undefined reference to 'ScriptC_example::ScriptC_example(android::RSC::sp<android::RSC::RS>)'
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
Can you please fix the issue for AGP 3.6.0-alpha02 and send it back to me?
You can include classpath 'com.android.tools.build:gradle:3.6.0-alpha02' in your build script
da...@google.com
Hello,
Thanks for getting back! I've updated the project now to support that version of the plugin, so it should resolve the include file correctly.
Please let me know if I can do anything else to help
Thanks for getting back! I've updated the project now to support that version of the plugin, so it should resolve the include file correctly.
Please let me know if I can do anything else to help
da...@google.com
Thank you! That worked wonders. I believe I have a solution for this issue. I will notify you when it is merged.
er...@browne.name
That's great news, thanks a lot!
da...@google.com
Hello again. Have you any notion of how long it will take for the fix to get into production? Thank you!
al...@gmail.com
I'm currently working on it. Should be coming out soon.
da...@google.com
Hi,
Thanks for working on this, and sorry to ask again, but is there any update on when this will be ready?
We haven't been able to release an app update in over a month because the Play Store interprets it as not having 64-bit support, so this is becoming increasingly urgent for us.
Is there anything we can do to help with it?
Thanks for working on this, and sorry to ask again, but is there any update on when this will be ready?
We haven't been able to release an app update in over a month because the Play Store interprets it as not having 64-bit support, so this is becoming increasingly urgent for us.
Is there anything we can do to help with it?
Description
Steps to reproduce:
- Clone this demo repo:
- Run the tests in the testdatabindingcoverage with coverage in Android Studio 3.3 RC1
- Coverage should be null
- Open activity_main.xml layout file and remove the `layout` tag (of course, move the xmlns imports to the ConstraintLayout)
- Run the coverage again and it should not be null anymore