Release 2.2.1

[kelson42]

Related to #108

[kelson42]

@mgautierfr @MohitMaliDeveloper Why the CI does not pass? Does the API has changed?

[mgautierfr]

Why the CI does not pass? Does the API has changed?

This is a crash in libzim. I don't know why yet. But it is not a API change.

@MohitMaliDeveloper, I've try to build this PR locally and a ./gradlew build first starts to update gradle to 8.4 and then it tell me I need Java 17. But I have set Java 11 explicitly on my side because we were not supporting Java 17. Do we have changed something on this side ?

[MohitMaliFtechiz]

@mgautierfr The gradle 8.4 requires JAVA 17 to run, we upgraded the java version when we added support for Android 14(SDK 34) in #97.

[kelson42]

@mgautierfr The gradle 8.4 requires JAVA 17 to run, we upgraded the java version when we added support for Android 14(SDK 34) in #97.

Please list very clearly the prerequisites which should be fullfilled to compile in the README

[mgautierfr]

@MohitMaliFtechiz

The CI now failing with this error:

> Task :lib:lintDebug FAILED
/home/runner/work/java-libkiwix/java-libkiwix/lib/build.gradle:36: Error: Not targeting the latest versions of Android; compatibility modes apply. Consider testing and updating this version. Consult the android.os.Build.VERSION_CODES javadoc for details. [OldTargetApi]
        targetSdk 34
        ~~~~~~~~~~~~

   Explanation for issues of type "OldTargetApi":
   When your application runs on a version of Android that is more recent than
   your targetSdkVersion specifies that it has been tested with, various
   compatibility modes kick in. This ensures that your application continues
   to work, but it may look out of place. For example, if the targetSdkVersion
   is less than 14, your app may get an option button in the UI.

   To fix this issue, set the targetSdkVersion to the highest available value.
   Then test your app to make sure everything works correctly. You may want to
   consult the compatibility notes to see what changes apply to each version
   you are adding support for:
   https://developer.android.com/reference/android/os/Build.VERSION_CODES.html
   as well as follow this guide:
   https://developer.android.com/distribute/best-practices/develop/target-sdk.
   html

   https://developer.android.com/distribute/best-practices/develop/target-sdk.html

1 errors, 0 warnings

FAILURE: Build failed with an exception.

I don't have it on my side when compiling locally.

[kelson42]

@mgautierfr Nice but what have you fixed, can we link a PR?

[mgautierfr]

See kiwix/kiwix-build#709

[kelson42]

@mgautierfr OK, but then we should not continue tomlink to the libzim here and this should reduce the overall size of the java-libkiwix package?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 93.23%. Comparing base (29f194f) to head (4f17f7c).
Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##               main     #109   +/-   ##
=========================================
  Coverage     93.23%   93.23%           
  Complexity      237      237           
=========================================
  Files            47       47           
  Lines           325      325           
  Branches          3        3           
=========================================
  Hits            303      303           
  Misses           19       19           
  Partials          3        3           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[MohitMaliFtechiz]

@MohitMaliFtechiz

The CI now failing with this error:

> Task :lib:lintDebug FAILED
/home/runner/work/java-libkiwix/java-libkiwix/lib/build.gradle:36: Error: Not targeting the latest versions of Android; compatibility modes apply. Consider testing and updating this version. Consult the android.os.Build.VERSION_CODES javadoc for details. [OldTargetApi]
        targetSdk 34
        ~~~~~~~~~~~~

   Explanation for issues of type "OldTargetApi":
   When your application runs on a version of Android that is more recent than
   your targetSdkVersion specifies that it has been tested with, various
   compatibility modes kick in. This ensures that your application continues
   to work, but it may look out of place. For example, if the targetSdkVersion
   is less than 14, your app may get an option button in the UI.

   To fix this issue, set the targetSdkVersion to the highest available value.
   Then test your app to make sure everything works correctly. You may want to
   consult the compatibility notes to see what changes apply to each version
   you are adding support for:
   https://developer.android.com/reference/android/os/Build.VERSION_CODES.html
   as well as follow this guide:
   https://developer.android.com/distribute/best-practices/develop/target-sdk.
   html

   https://developer.android.com/distribute/best-practices/develop/target-sdk.html

1 errors, 0 warnings

FAILURE: Build failed with an exception.

I don't have it on my side when compiling locally.

This was an lint issue. It was because we are added the support for the SDK 34(Android 14), and the latest version of Android is 15 That's why lint was giving the error for it. Now CI is green.

[mgautierfr]

OK, but then we should not continue tomlink to the libzim here and this should reduce the overall size of the java-libkiwix package?

But libkiwix do not include all symbol of libzim. It include only the one used by libkiwix. For exemple if libkiwix never call the search function (this is a example, I haven't check), zim's seach function is not in libkiwix.
Libkiwix has all symbol needed to use libkiwix, not to use libzim.

I have to mention that this kind of issue was already known a long time ago. I've accepted to do it because we don't really have the choice, but we are doing crafty thing when we distribute pre-compiled libraries and we will have some issue again (see kiwix/kiwix-build#418)

[kelson42]

@mgautierfr Then the libkiwix should rely dynamically (at least for Android) to the libzim. We face here a serious waste of memory (both storage and live). Why we don't do that?

[mgautierfr]

We face here a serious waste of memory (both storage and live)

You will have to give number. I remember you that last time, your were saying it was not a problem 😉

Why we don't do that?

Because initially we were binding only libkiwix (hence the name of the repository)

And even if we do as you propose, we are testing with non android dedicated libraries (linux-x86_64). So tests would be broken too (and it is a good thing we do the same things here as testing under linux give us "good" confidence that android may work the same).

And even if we move libzim code out of libkiwix.so, it would be the same for xapian/icu4c/zlib which are used by both projects. As I said, the real solutions are:

• Build everything as dynamic library (less code duplicate, we can update a library without changing other (at ABI break exception), but lot of files to distributes, but some unused code included (as libzim creator)).
• Build everything statically (one .so (the wrappper), but we have to compile all libraries "together" to be sure dependencies are not duplicated)
• Let end projects (java-libkiwix here) build there own dependencies, with there own version configuration (which is kind of the same thing that previous point but without prebuild library)