Support 64-bit architectures

[ilyamuromets]

According to this post https://android-developers.googleblog.com/2017/12/improving-app-security-and-performance.html
In August 2019, Google Play will require that new apps and app updates with native libraries provide 64-bit versions in addition to their 32-bit versions.

Do you plan to support for 64-bit architectures?

[eckoj433]

I am also waiting for this. This is an extremely useful library, and as of right now i m highly dependant on it, so it would be really nice to be able to keep using it :)

[AlexTrotsenko]

I see, that there is PR, but it's nor merged. May be could be useful for somebody to use it as it is or refine and finish it: #380

[AlexTrotsenko]

@irbull Sorry for disturbing, but I just want to highlight, that on August 2019 Google Play will block app uploading of the apk without 64-bit version of the native libs.

[GrahamBorland]

@irbull It's now 2019 and the deadline for updating Android apps to include 64-bit architectures is now just a few months away. Any chance you could post a status update here to let us know if 64-bit support is likely to be forthcoming?

It's getting time-critical. I see that #380 was opened but seems to have stalled.

Thanks!

[irbull]

I have managed to build an arm64-v8a native lib for J2V8 and deploy that to my Pixel 2. But here is where I need help. What is the expectations for a J2V8 aar file with 64 bit support, what should it include? (armeabi-v7a and arm64-v8a )? Also, does it need both x86 and x86_64 native libs?

Also, I tried to build x86_64 and it fails to cross-compile the NodeJS dependencies. I will investigate this a bit more.

[GrahamBorland]

@irbull This should cover what we need for Android:

armeabi-v7a, arm64-v8a, x86, x86_64

[irbull]

@GrahamBorland Thanks! So just to clarify, if we had an aar file with a .so file for each one of those architectures, that would work? It will make the .aar twice the size it is now.

[GrahamBorland]

@irbull That is correct. It will bump up the size of the .aar and the eventual .apk, but we have the option to use APK splitting or App Bundles to mitigate the effect for end-users who download the app.

[irbull]

I have managed to build x86_64 and arm64 from master in addition to x86 and arm in the following commit (23e3706). All combined, it produces an aar that is 26Mb. I have tested the arm64 builds on my Pixel 2 and the x86_64 builds on an emulator. I will publish the aar to maven central this week.

As mentioned, this is only from master. I have recently broke some API around Array Buffers because the use of the API leads to segfaults and I will be releasing J2V8 version 5.x. But I also understand that not everyone will want to migrate to the latest J2V8 just to get 64-bit support. I will investigate how this change can be back ported to J2V8 4.x.

Finally, I'm going to be reducing the scope of this project to focus soley on V8 on Android. See #441 for more details.

[GrahamBorland]

@irbull Thank you!

Regarding --api 23, https://developer.android.com/ndk/guides/standalone_toolchain seems to imply that 64-bit builds should work for API level 21.

The --arch argument is required, but the API level will default to the minimum supported level for the given architecture (currently 16 for 32-bit architectures and 21 for 64-bit architectures).

[irbull]

@GrahamBorland Thanks! I'll switch to 21. Honestly, I was pulling my hair out for a few days trying to get these working, and I guess I just tried 23 at one point and left it. (turns out the --cross-compilation flag was the missing piece of magic I needed).

I'd like to keep the API level as low as possible, so if 21 works, I'm happy with that.

[eckoj433]

Did anyone manage to compile an .aar for 64 bit? and if so would it be possible to share it? was not able to find it on mavencentral

[GrahamBorland]

Here's the latest post from Google with a more detailed timeline and migration guide.
https://android-developers.googleblog.com/2019/01/get-your-apps-ready-for-64-bit.html

[JessHolle]

An official build containing official 64-bit Android ARM binaries would be very, very helpful about now!

[ltasquier]

Hi @irbull ,hi all! is it possible to have a precompiled libj2v8.so version for arm64-v8a and x86_64? Or, in alternative, is it possible to update the maven repository with the new release? Thanks in advance

[GrahamBorland]

@irbull Is there any specific help you need to get 64-bit builds shipped? If you let us know what is needed, maybe one of us can offer some help.

The clock is ticking. :)

[JessHolle]

I ended up building myself from HEAD, but couldn't figure out the "right" way to build 64-bit much less a "fat" 32/64-bit AAR file, so I ended up hacking a 64-bit build and pieces together a far AAR by hand. Obviously not ideal. An official fat AAR build (and obvious or documented means of producing this) is really needed.

[whkailee]

@irbull Hi, when will 64bit J2v8 release? It's running out of time.

[irbull]

I finally managed to get the jar signing working and pushed to maven central the lastest code from master.

<!-- https://mvnrepository.com/artifact/com.eclipsesource.j2v8/j2v8 -->
<dependency>
    <groupId>com.eclipsesource.j2v8</groupId>
    <artifactId>j2v8</artifactId>
    <version>5.0.101</version>
</dependency>

This doesn't include the fix @JessHolle has for library loading. I'll get that in next. The build number is a little wacky, that's about the number of attempts it took me. 😫

I can also be used as a gradle dependency:

implementation 'com.eclipsesource.j2v8:j2v8:5.0.101@aar'

[JessHolle]

I'll be anxiously awaiting an official build containing the library fix -- so I can get off my own hacked one!

[irbull]

Just for a bit of transparency on what I'm doing here:

• Because the signing required certs and keystores, I did it in a branch and pushed it directly to our build server. When it finally worked, that resulted in 5.0.101
• There were only a few changes in the end, but it took me a lot of trial and error. I've now squashed all the work I did and pushed it to GitHub master (marked as version 5.0.102). It uses environment variables for the keys, so nothing should sensitive should be in the public repo.
• This is currently being picked up by the build server and building now (which, if successful should result in 502).
• If this works, I'll pull in the change by @JessHolle for library loading, and that should result in 503
• If that works, I'll try to pull the signing work to the 4.8-maintenance branch and see if I can get a build with that too.

[GrahamBorland]

@irbull Thank you! Is there a way I can (remotely) buy you a few beers?

[irbull]

We now have 64-bit support in both the 4.8 and 5.0 streams.

In gradle:
implementation 'com.eclipsesource.j2v8:j2v8:5.0.103@aar'
implementation 'com.eclipsesource.j2v8:j2v8:4.8.4@aar'

or in a maven pom

<dependency>
  <groupId>com.eclipsesource.j2v8</groupId>
  <artifactId>j2v8</artifactId>
  <version>4.8.4</version>
  <type>aar</type>
</dependency>

or

<dependency>
  <groupId>com.eclipsesource.j2v8</groupId>
  <artifactId>j2v8</artifactId>
  <version>5.0.103</version>
  <type>aar</type>
</dependency>

All those builds contain the binaries for x86, x86_64, arm and arm64. If you call
v8.getSCMRevision(); in your application, you'll see the commit hash that the artifact was built against. For 4.8.4 it's 8a79c8b and for 5.0.103 it's e6ac51a.

As for beers, I live in the Pacific Northwest and travel to Germany a few times a year. If anyone is around Victoria BC, or Karlsruhe Germany, and wants to go for a drink and chat JNI, OSS Java or whatever, I'm usually up for a drink. Thanks, everyone for all your patience and pointers with this issue.

[doneill]

@irbull

I'd like to keep the API level as low as possible, so if 21 works, I'm happy with that.

Is it possible to lower the API level to 16 for 32-bit archs?

[irbull]

Does this mean we need different API levels for 32 vs 64 bit?

[GrahamBorland]

I'm not even sure how one could easily do that. In 2019, API level 21 is a sensible, realistic and pragmatic minimum version. Anyone who needs to support older versions can stick with the older (32-bit-only) version of J2V8, or may need to have a separate build of their app for older Android versions.

Android 4.4 is six years old now.

[sgopi93]

@GrahamBorland We have pain that the Android have Fragmentation Issue. Google itself trying to solve this using Project treble. We cannot omit just because Android 4.4 is 6 years old. Even google recommends developers to support from 4.3 (API level 16). At least we should support from 4.4.

[JessHolle]

Personally I concur with @GrahamBorland -- Android 4.x is ancient history in my book. Android 5.x is borderline.

But I understand that different apps have different requirements in terms of their ability to reach old devices. Which is to say, supporting old OS versions is fine/good if someone manages to accomplish that, but not an itch I'd personally spend time trying to scratch. I'd be most concerned about Android 6 and higher and looking forward, e.g. to newer V8 versions.

[doneill]

Yes supporting api 19+ can be done, I understand the takes on versions, but Google still documents 4.4 and there are industries where older devices are still being used in the field.