blackkara commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@nealsanche Thanks for the details.

nealsanche commented 8 years ago

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 commented 8 years ago

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

kneth commented 8 years ago

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 commented 8 years ago

3660

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

littleGnAl commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

kneth commented 8 years ago

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

littleGnAl commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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

Zhuinden commented 7 years ago

Any progress?

kneth commented 7 years ago

We are working on it - as part of https://github.com/realm/realm-core/pull/1883

Zhuinden commented 7 years ago

Now it's probably NDK R14

kneth commented 7 years ago

@Zhuinden Indeed. And R14 seems to fix the LTO issues too.

Qubitium commented 7 years ago

@kneth Please kindly nudge the core team to speed it up, for the sake of java lib in your next meet-up or conference. The java side needs this much more than the cocoa side, urgency-wise. Who know what other compile/tool-chain bugs R14 have fixed along the way.

https://github.com/realm/realm-core/issues/1883

Cocoa side can operate happily currently without CMAKE, but java can get a hospital grade injection with R14 if it does resolve the inconsistent LTO and other related wtf bugs since the v2 version.

cmelchior commented 7 years ago

@diegomontoya They are working on it as much as possible, and rest assured that we want to upgrade to R14 just as much as you.

Zhuinden commented 7 years ago

https://github.com/realm/realm-core/pull/1883 seems to be getting up to speed, once it's merged does that mean armeabi is coming back?

cmelchior commented 7 years ago

Yes

gkonovalov commented 7 years ago

Hey everybody! Thank you for your awesome project.

Anybody know when will be release with armeabi inside?

Zhuinden commented 7 years ago

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

denizmveli commented 7 years ago

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

kneth commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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

Zhuinden commented 7 years ago

Switch to CMake PR was merged into Realm-Core

https://github.com/realm/realm-core/pull/1883

cmelchior commented 7 years ago

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 commented 7 years ago

@cmelchior

Zhuinden commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

No, NDK18 flat out removes support for armeabi.

konatwhitesky commented 5 years ago

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

cmelchior commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 4 years ago

Outdated and replaced by https://github.com/realm/realm-java/pull/6460

realm / realm-java

Upgrade to NDK R13 + Re-add armeabi #3506

3660