Cannot allocate memory

[AriDeve]

Versions

• Python: 3.10
• OS: Windows 10
• Buildozer: 1.4.0

Description

buildozer -v android debug running into a problem with the gradle build, it throws errors and never completes. All the errors it throws are about memory, for example:
.buildozer/android/platform/build-arm64-v8a_armeabi-v7a/dists/myapp/build/intermediates/merged_jni_libs/debug/out/arm64-v8a/libhidapi.so: Cannot allocate memory

How would one solve this issue, as I haven't found a way to increase the allocated memory, and cannot think of any other solutions?

[RobertFlatt]

It is possible this is related to WSL 1, upgrade to WSL 2

[Marcinosoft]

I had similar 'Cannot allocate memory' issue.

[DEBUG]:        > Task :mergeReleaseJniLibFolders FAILED
[DEBUG]:        ERROR:Resource and asset merger: 1 exception was raised by workers:
[DEBUG]:        A failure occurred while executing com.android.build.gradle.internal.tasks.Workers$RunnableWrapperWorkAction
[DEBUG]:
[DEBUG]:            Cause 1: org.gradle.workers.internal.DefaultWorkerExecutor$WorkExecutionException: A failure occurred while executing com.android.build.gradle.internal.tasks.Workers$RunnableWrapperWork

Caused by: java.lang.RuntimeException: java.nio.file.FileSystemException: ....../libs/armeabi-v7a/xxxxxxxxxxxxxxxxxx -> ...../xxxxxxxxxxxxxxxxxx: Cannot allocate memory

In xxxxxxxxxxxxxxxxxx there was one of following files, randomly:

gdb.setup
gdbserver
libSDL2.so
libSDL2_image.so
libSDL2_mixer.so
libSDL2_ttf.so
libcrypto1.1.so
libffi.so
libhidapi.so
libmain.so
libpython3.9.so
libsqlite3.so
libssl1.1.so

I spend two days to figure out how to solve it, and in my case it was because of openjdk-17-jdk.
Buildozer 1.4.0 supports at least openjdk-11-jdk up to openjdk-17-jdk.
I installed openjdk-17-jdk as suggested here:
https://buildozer.readthedocs.io/en/latest/installation.html
or here:
https://github.com/kivy/buildozer/blob/master/docs/source/installation.rst#android-on-ubuntu-2004-and-2204-64bit

sudo apt install -y git zip unzip openjdk-17-jdk python3-pip autoconf libtool pkg-config zlib1g-dev libncurses5-dev libncursesw5-dev libtinfo5 cmake libffi-dev libssl-dev

I checked it with following environments with no success on two separate laptops:

Windows 10 Pro 21H1, Buildozer 1.4.0, WSL v1 with Ubuntu 20.04, openjdk-17-jdk
Windows 10 Pro 21H1, Buildozer 1.4.0, WSL v2 with Ubuntu 20.04, openjdk-17-jdk
Windows 10 Pro 21H1, Buildozer 1.4.0, WSL v1 with Ubuntu 22.04, openjdk-17-jdk
Windows 10 Pro 21H1, Buildozer 1.4.0, WSL v2 with Ubuntu 22.04, openjdk-17-jdk

My Kivy project with virtual environment base on Python 3.8.

I tried clean Ubuntu installations, new Kivy projects, old projects which was previously working with Buildozer 1.2.0, removing .buildozer folder from project dir, upgrading gradle from 7.4.1 to 7.4.2, change memory settings (GRADLE_OPTS, JAVA_OPTS), a lot of wasted time.

I tried to build with:

buildozer -v android debug

and

buildozer -v android release

Strange, that from time to time I was able to build aab package, but never apk, setting following param of buildozer.spec:

# (str) The format used to package the app for release mode (aab or apk or aar).
android.release_artifact = apk

When this line was commented out aab file was able to build, but not always, sometimes 'Cannot allocate memory' also occured but not too often.

Then I started to thinking that this may happen because of Java 17. I wasn't able to uninstall it completely using:

sudo apt remove openjdk-17-jdk
sudo apt remove openjdk-17-jre
sudo apt-get purge openjdk-17-jdk
sudo apt-get purge openjdk-17-jre
sudo apt-get --purge --autoremove openjdk-17-jdk
sudo apt-get --purge --autoremove openjdk-17-jre

Java 17 was still present and it was default one in the path. I'm not an Ubuntu expert, I have no clue why Java 17 was still available.
I checked it using:

java --version

and 17 was still available. Strange.

So I uninstalled Ubuntu, installed it again from Microsoft Store, set to WSL v1 using:

wsl --set-default-version 1

then installed all Buildozer required components, but with Java 11 instead of 17, based on pages mentioned above:

sudo apt install -y git zip unzip openjdk-11-jdk python3-pip autoconf libtool pkg-config zlib1g-dev libncurses5-dev libncursesw5-dev libtinfo5 cmake libffi-dev libssl-dev
pip3 install --user --upgrade Cython==0.29.19 virtualenv
pip3 install --user --upgrade buildozer

And yes, now apk build process works like a charm.

Afterwards, I also faced with another build issue:

[DEBUG]:        > Task :lintVitalRelease FAILED
[DEBUG]:        /mnt/c/Kivy/my_project/.buildozer/android/platform/build-armeabi-v7a/dists/my_project/build.gradle:31: Error: Google Play requires that apps target API level 30 or higher.
[DEBUG]:         [ExpiredTargetSdkVersion]
[DEBUG]:                targetSdkVersion 27
[DEBUG]:                ~~~~~~~~~~~~~~~~~~~
[DEBUG]:
[DEBUG]:           Explanation for issues of type "ExpiredTargetSdkVersion":

building with:

buildozer -v android release

I solved it by following line change of buildozer.spec:

	# (int) Target Android API, should be as high as possible.
	android.api = 33

But it wasn't also easy, as long I realized that there is probably a Buildozer bug. Buildozer does not always update targetSdkVersion according to android.api param change.
Maybe I will register it as separate Buildozer issue. Till then here is my solution:

https://stackoverflow.com/questions/72746288/buildozer-android-api-doesnt-change/74311692#74311692

So in my case it wasn't WSL version related issue. It worked same on v1 and v2. And it was not Ubuntu version related issue as well.
It was because of latest available Java 17 for Ubuntu. Maybe it's buggy, maybe this issue will be fixed in future releases of Java 17 or Gradle, but currently I recommend to downgrade to Java 11 and check if your problem will be solved.

[RobertFlatt]

Thanks for the info on jdk17 and Gradle.

But it wasn't also easy, as long I realized that there is probably a Buildozer bug. Buildozer does not always update targetSdkVersion according to android.api param change.

FYI https://github.com/Android-for-Python/Android-for-Python-Users#changing-buildozerspec

Also FYI https://github.com/Android-for-Python/Android-for-Python-Users#androidapi

[Marcinosoft]

FYI https://github.com/Android-for-Python/Android-for-Python-Users#changing-buildozerspec

Thanks. I wasn't aware of this. I was thinking that buildozer.spec is read and apply on every build. I changed other values in the past and it was always applied into apk. I never used buildozer appclean.
Really unclear sentence "If buildozer.spec is changed the change probably won't propagate into the apk on the next build."
"Probably"? what does it mean. It's kind a random behaviour, or maybe not every buildozer.spec param change will be applied on next build?

buildozer appclean in fact removes whole .buildozer folder! It causes that whole environment have to be redownloaded and compiled which is really long running process. It make no sense to do it for tiny change like android.api value.
Also your previous running builds based on for example older Buildozer like 1.2.0 or 1.3.0 won't longer work without Buildozer update to 1.4.0 and JDK upgrade to 11, as long ndk url used in pre 1.4.0 is no longer valid (https://dl.google.com/android/repository/android-ndk-r23b-linux-x86_64.zip). It may be confusing, when your builds worked fine but suddenly after appclean they won't.

In my opinion it would be better to read and apply all parameters from buildozer.spec on every buildozer -v android release and buildozer -v android debug by default to avoid suprises.

[github-actions]

👋 @AriDeve, we use the issue tracker exclusively for bug reports and feature requests. However, this issue appears to be a support request. Please use our support channels to get help with the project.
Let us know if this comment was made in error, and we'll be happy to reopen the issue.

[Marcinosoft]

Just for update: this case is still valid for latest Kivy 2.3.0, Buildozer 1.5.0, and Ubuntu 20.04.6 and 22.04.3 running on WSL v1 and v2.
In short: switching OpenJDK from 17 to 11 makes Gradle successfull apk builds.

Install OpenJDK 11 on Ubuntu by running:
sudo apt install -y openjdk-11-jdk

Make OpenJDK 11 as default Java by running:
sudo update-alternatives --config java
and make selection of:
/usr/lib/jvm/java-11-openjdk-amd64/bin/java

[RobertFlatt]

FYI I do not see the same issue - I don't know why my experience is different.

How much physical memory does the computer have?
Does the issue occur building 'Hello World'?
Does the issue occur building an app that has user specified Java code or packages?

Because you use an old Windows version, I'd wonder if you are using old hardware with insufficient physical memory for this task. So I'd look at the WSL process memory (see below), the default is going to depend on the Windows physical memory. It is possible to change the WSL process memory (see below) but if there is insufficient physical memory this won't help. Similarly for the Java heap size.

I'm not involved with development here, just a user driving by.

I use:

Windows 11
WSL2
JDK 17
Buildozer 1.5 with default p4a

My .wslconfig is not the default for reasons unrelated to Buildozer/p4a .

C:\Users\Bobf>type .wslconfig
[wsl2]
memory=20GB
swap=16GB

My Ubuntu meminfo starts with

~>cat /proc/meminfo
MemTotal:       20485364 kB
MemFree:        18588696 kB
MemAvailable:   19072376 kB