Upgrade to NDK R13 + Re-add armeabi

[blackkara]

The latest version's changelog says

armeabi is not supported anymore.

But i'm seeing armeabi is still written in How big is the Realm Base library?

include 'armeabi', 'armeabi-v7a', 'arm64-v8a', 'mips', 'x86', 'x86_64'

1- Probably you will update this part in website too?

2- if i use Realm 2.0.0 in upcoming update of my app, means stopping support for armeabi devices on market ?

[cmelchior]

• Yes, we should update the website. Sorry about that.
• The only armeabi devices left are extremely ancient which is also why Google is no longer officially supporting it as a default. So it shouldn't have any practical impact.

Where it might make a difference is that if your app also contain other native code that only comes as armeabi, in that case the device tries to load the lowest common denominator which will fail.

Depending on the scope of the problem we will probably try to provide a solution in those cases. You can follow the discussion here: #3508

[nealsanche]

The problem is, Google Play Store does not allow you to upload a new APK that does not support ALL of the previous ABIs. From what I can tell, it outputs a cryptic error that looks like the following:

This configuration cannot be published for the following reason(s):
It is forbidden to downgrade devices which previously used M permissions (target SDK 23 and above) to APKs which use old style permissions (target SDK 22 and below). This occurs in the change from version 22 (target SDK 24) to version 16 (target SDK 8).
Some devices are eligible to run multiple APKs. In such a scenario, the device will receive the APK with the higher version code.

It seems, this error may be caused by what this fellow mentions:
http://stackoverflow.com/a/37074814/453083

In my case, I had been using an old version of Realm, 1.2.0. Then I put my APK into beta on Google Play. Then I updated to realm 2.0.2 (which removes the armeabi native libraries, and can no longer publish the APK to Google Play.

Anyway, I'm trying to figure out a workaround, but so far no luck.

EDIT: Reverting back to Realm 1.2.0 allows me to upload to Google Play without the mentioned error. I'm expecting you're going to see this issue a lot more.

[kneth]

@nealsanche Thanks for the details.

[nealsanche]

In my case, I'm still trying to get some information from Google about it. I think what's happening is that the APK I'm uploading doesn't include armeabi, so it would cause people with that native platform to get an older version of my app from the play store, which in this case was a version prior to my upgrading to the new permission model. So, it's not directly related to your removal of armeabi. I'm sure there is a way around it. I just have to think about it and see what Google says.

[cmelchior]

Hi @nealsanche Thanks for the update. Your reasoning sounds correct, but getting something from Google to clarify it sounds like a good idea.

[kneth]

To get armeabi back, we need to upgrade to a newer version of NDK and start compiling with clang. We really wish to do that but I can't give any time estimate.

[zaki50]

#3660
API Level 13 or below (except API Level 10) of official emulators only support armeabi.

[littleGnAl]

But I get this in my samsung galaxy note3 with android 5.0. In my project I use abiFilters 'x86', 'arm64-v8a', 'armeabi', sorry for not familiar of ndk, and it's only way to revert the version below 2.0 to solve the problem?

[zaki50]

Why armeabi instead of armeabi-v7a?
If you couldn't change it to armeabi-v7a, reverting to below 2.0 is the only way for now.

[littleGnAl]

@zaki50 Because the other thirty lib not provide the armabi-v7a 's .so, so I can't change it.

[kneth]

@littleGnAl Can you tell us which 3rd party library you are using?

[littleGnAl]

@kneth That is a IM provider's sdk easemob. And the fact is that there are lots of sdk providder only provide the'x86', 'arm64-v8a', 'armeabi''s so. I think Realm should not remove armabi so, because gradle abiFilters is really a good tool to remove that personally.

[nealsanche]

Aside: I got pretty bad information from Google about this. What I ended up having to do is release the app with Realm 1.2.0 into production from beta on Google Play. Then, upgrade to Realm 2.0.0, and release another version to production. Any other way, and I would get an error that people with armeabi would get a version of the app that didn't have support for the new permission model. Which Google doesn't allow. Releasing the version with Realm 1.2.0 provided Google Play with a new data point, that was at at least API 23 which had armeabi as well, and this made Google Play happy when I upgraded to 2.0.0 which removed armeabi.

The only downside here is that people with armeabi devices will now get the version of my app where it was released at 1.2.0, and no further automatic updates.

I probably won't have any users like that.

[Zhuinden]

@nealsanche by 2.0.0 you mean 2.0.2 or above, right?

[gkonovalov]

Hey everybody!
Thank you for your awesome project.

Anybody know when will be release with armeabi inside?

[Zhuinden]

It's amazing that Emanuelez has been working on this for months but it's still in progress. Poor Emanuelez.

[denizmveli]

What's the status here? We're stuck and can't update realm to fix bugs in the older version.

[kneth]

@denizmveli We have made a lot of progress in switch to CMake for all the packages which Realm Java depends on. Switching to CMake will make it possible to start using a recent NDK, and adding armeabi back will be easier (clang has better support for atomic). We have not be able to finalize it but I hope that we can do it very soon. One headache is that compiling OpenSSL for Android with a recent NDK is not trivial.

[molind]

@kneth Just FYI we use LibreSSL in our project and it's compiles successfully using last NDK. LibreSSL could be drop-in replacement for OpenSSL.

[kneth]

@molind Thanks for sharing. Last time we tried LibreSSL, we had to apply 3 or 4 patches so it is good news.

[Zhuinden]

Switch to CMake PR was merged into Realm-Core

realm/realm-core#1883

[cmelchior]

Yup, unfortunately, that is the only first step (albeit a very major one). Now we also need our sync parts to adopt those changes.

[Zhuinden]

@cmelchior

[Zhuinden]

@cmelchior jokes aside, considering I don't see realm-sync repository I'm kinda curious if there's any chance this could happen before Realm 5.0?

Although as the saying goes, "patience breeds armeabi"

but maybe I should just figure out the difference between the different types of armeabi (armeabi-v7a, arm64-v8a, and if any of them are synonymous with normal armeabi as of late)

[Zhuinden]

Good news is that if you upgrade to NDK R18 when it comes out, apparently you'll no longer need to worry about armeabi

[alexcohn]

@nealsanche:

The only downside here is that people with armeabi devices will now get the version of my app where it was released at 1.2.0, and no further automatic updates.

Note that ARMV5 devices (which are not compatible with armeabi-v7a), cannot have API 23, and for them the runtime permissions aren't relevant.

[konatwhitesky]

Hello is there an update on this? We are using a third party lib (we cannot disclose exactly which) that is only available in armeabi and there is no time estimate on when armeabi-v7a will become available. We also need to run a service as a separate process on Android, which requires Realm 4.9.0.

Is there a workaround for getting a recent version of Realm compiled in armeabi?

[konatwhitesky]

Hi Christian, can you please explain how support for NDK18 is going to help? Will it result in Realm again having armeabi binaries? Thank you.

[Zhuinden]

No, NDK18 flat out removes support for armeabi.

[konatwhitesky]

Ok, do I understand correctly then that it is impossible to have Realm 4.9+ work on armeabi?

[cmelchior]

@konatwhitesky If I remember correctly we only removed arm support because Google deprecated support for it. There isn't anything that technically prevents you from actually building the armeabi binary (except changes or bugs in tool/build scripts). This was done in Realm Java 2.0

Currently, it would mean building https://github.com/realm/realm-core and Realm Java yourself:. See https://github.com/realm/realm-core/blob/master/how-to-build.md#building-for-android-ios-watchos-and-tvos and you will need to re-add armeabi to this list https://github.com/realm/realm-java/blob/master/realm/realm-library/build.gradle#L69.

But that is only possible as long as we use NDK r10e. With r18b this option goes away.

Also keep in mind that Google requires you to ship proper 64 bit binaries by August 2019, so libraries will not be able to get away with just providing armeabi code after this date. Apps doing that would no longer be allowed in Play Store: https://android-developers.googleblog.com/2019/01/get-your-apps-ready-for-64-bit.html

[enh]

Hello is there an update on this? We are using a third party lib (we cannot disclose exactly which) that is only available in armeabi and there is no time estimate on when armeabi-v7a will become available. We also need to run a service as a separate process on Android, which requires Realm 4.9.0.

Is there a workaround for getting a recent version of Realm compiled in armeabi?

armeabi is a subset of armeabi-v7a, so this shouldn't matter... can't you just put the third party prebuilts in your armeabi-v7a directory?

[st-f]

armeabi is a subset of armeabi-v7a, so this shouldn't matter... can't you just put the third party prebuilts in your armeabi-v7a directory?

That sounds logical but it definitely doesn't work.

[cmelchior]

Outdated and replaced by #6460