Skip to content

Improving .so loading by using the ReLinker library#1771

Merged
kneth merged 27 commits intomasterfrom
kg/bug/improving-so-loading-using-relinker
Jan 11, 2016
Merged

Improving .so loading by using the ReLinker library#1771
kneth merged 27 commits intomasterfrom
kg/bug/improving-so-loading-using-relinker

Conversation

@kneth
Copy link
Contributor

@kneth kneth commented Nov 13, 2015

We have seen a number of reports on problems with loading .so files. The origins can be that the .so loader in Android is known to be unreliable and some end-users do not use Google's Play Store (often the case in China).

TODO:

@realm/java

@kneth kneth added the Review label Nov 13, 2015
@emanuelez
Copy link
Contributor

We should add ReLinker as a dependency in Gradle and not just copy pasting the file

@kneth kneth self-assigned this Nov 13, 2015
@cmelchior
Copy link
Contributor

Agreeded. We can can shadow it the same way we do JavaWriter to avoid versioning conflicts from other libraries

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove FIXME?

@kneth
Copy link
Contributor Author

kneth commented Nov 13, 2015

@cmelchior You had the opposite opinion yesterday but I'll be happy to change it back.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens if the context is null?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We check in line 245 and throw an exception.

@cmelchior
Copy link
Contributor

Alternative suggestion to the changelog: "Improved .so loading by using ReLinker (link)"

@cmelchior
Copy link
Contributor

@kneth Yes, I believe I might accidentally have voiced that opinion, sorry. Shadowing does the same thing, except we don't have to add the file to the code base.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove comment. Doesn't add any info.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't this cause problem with our JNI testing? If the case is only about Table, the Builder will not be called. And also, I think put this in a static block would be a good idea since it only needs to be ran once.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem with the static block is that it doesn't have access to a Context.

@beeender
Copy link
Contributor

The failed monkeyTest is because of the ReLinker class is not packed in the final apk file. Gradle experts @emanuelez @zaki50 ?

@zaki50
Copy link
Contributor

zaki50 commented Nov 18, 2015

I think we need add ReLInker to https://github.com/realm/realm-java/blob/master/gradle-plugin/src/main/groovy/io/realm/gradle/Realm.groovy#L14 or repackage ReLinker into realm-library

@emanuelez
Copy link
Contributor

@zaki50 That should not be needed as it should be handled as a transitive dependency, just like JavaWriter

@zaki50
Copy link
Contributor

zaki50 commented Nov 18, 2015

@emanuelez make sense. We need to add "https://jitpack.io" as a maven repository?

@emanuelez
Copy link
Contributor

Ohhh... yes! That's probably it!

@zaki50
Copy link
Contributor

zaki50 commented Nov 18, 2015

But should we avoid to implicitly add an maven repository?

@zaki50
Copy link
Contributor

zaki50 commented Nov 18, 2015

RealmConfiguration.Builder has another constructor Builder(File folder) and it does not load the native library.

@kneth
Copy link
Contributor Author

kneth commented Nov 19, 2015

Bump @realm/java

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing Javadoc for this method and loadLibrary() so the difference is clear.

@beeender
Copy link
Contributor

@diegomontoya When the problem happens, can you please check in the /data/data/<package-name/lib directory to see if the so file is the same with the newly installed version? If it is not, is it the previous version?

Can you please test if the Relinker solve this problem by calling Relinker to load the librealm-jni.so before calling any Realm functions

I really want to try this by myself but none of my phones can reproduce this issue...

And what does below mean?

Strange thing is, the library .so appears to be loaded correctly with System.loadLibrary() not triggering any errors.

@Qubitium
Copy link

@beeender The "NoClassDefNotFound" for io/realm/internal/SharedGroup for my case is not caused as result of the system unable to load the .so file aka System.loadLibrary() throwing errors. That was very strange.

Unfortunately I have use builds/installed hundreds of times on the device and yesterday was the first time ever I could reproduce this type of bug on any device. Next time I will make sure to freeze the /data/data path for future inspection. Too bad I wasn't thinking clearly at the time. Opportunity wasted on catching the bigfoot.

Strange thing is, the library .so appears to be loaded correctly with System.loadLibrary() not triggering any errors.

@kneth
Copy link
Contributor Author

kneth commented Jan 5, 2016

@diegomontoya Do you suggest that corrupted .so is the result of a bug in the package manager? It's going to be hard to fix that 😄

@Qubitium
Copy link

Qubitium commented Jan 6, 2016

@kneth Yes, I am suggesting there are two bugs here, one of which relink can fix. The first bug is that the install completely bonks the .so copy so there are no .so file to be found. Relink can fix this. But the issue I encountered appears to be the .so loading was completed without errors but still triggering the cryptic io/ream/internal/SharedGroup not found error. The second bug may be hopeless since it may mean the .so is actually corrupted but loadable.

@cmelchior
Copy link
Contributor

Fixed the last bug in the unit tests, so should be ready now @realm/java

@cmelchior
Copy link
Contributor

👍 from me, but I made the last change, so ... ;)

@beeender
Copy link
Contributor

retest this please

@beeender
Copy link
Contributor

👍

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure the annotations don't need to be added as apt?

kneth added 2 commits January 11, 2016 10:57
…om:realm/realm-java into kg/bug/improving-so-loading-using-relinker
kneth pushed a commit that referenced this pull request Jan 11, 2016
…-relinker

Improving .so loading by using the ReLinker library
@kneth kneth merged commit d7b401d into master Jan 11, 2016
@kneth kneth removed the Review label Jan 11, 2016
@kneth kneth deleted the kg/bug/improving-so-loading-using-relinker branch January 11, 2016 11:33
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 16, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants