Android Question copying resources takes too long

Marco Nissen

Active Member
Licensed User
Longtime User
Hi there,

I just switched my MacBook from intel to M1 max.
b4a runs on windows 11 ARM via parallels and I use the ARM JDK to compile which is good so far
only issue is: copying resources seems to take forever (switched off windows defender antimalware protection and firewall off, all files local in the VM, but still)
this also happens when there is no device connected
build type is release, via bridge (though not applicable here)
android 30

any ideas what I could try to fix this?
are there any additional hidden logs?

See below for the summary. 163 secs is too long ...

thanks
Marco

B4A Version: 11.80
Parse den Code. (1.88s)
Java Version: 11
Building folders structure. (1.60s)
Kompiliere den Code. (1.76s)
Kompiliere Layoutcode. (0.14s)
Organisiere Libraries. (0.05s)
(AndroidX SDK)
Ressourcen zusammenstellen (2.18s)
Ressourcen verknüpfen (2.16s)
Kompiliere generierten Java Code. (6.76s)
Suchen von Bibliotheken, die dexiert werden müssen. (0.02s)
Dex code (7.14s)
Dex merge (3.60s)
Kopieren von Bibliothek Ressourcen (163.17s)
ZipAlign file. (0.41s)
Signiere Paketdatei (privater Key). (0.72s)
Installiere Datei auf Gerät.
 

Marco Nissen

Active Member
Licensed User
Longtime User
I only have this project right now, and there are quite a few libraries included.
I need to check how I can export the entire list
when I create a new sample default type of project, there's no issue (with no extra libraries)

do you have a trace log of the copying process? then I could look which one takes long
 
Upvote 0

Marco Nissen

Active Member
Licensed User
Longtime User
I spend some time to deactivate each library to see which one causes the issue
it's Pdfium which has a 20MB AAR file - see here for the actual library
not sure what the issue is here - @DonManfred can you imagine any issue with the wrapper library?
 
Upvote 0

DonManfred

Expert
Licensed User
Longtime User
If you do not want to run the app on an Emulator you can delete the subfolders jni/x86 and jni/x86_64 from the AAR.

You maybe can delete other folders from the jni-folder if you do not plan to use the library on devices with these architectures.
- jni/arm64-v8a (probably needed)
- jni/armeabi-v7a (probably needed)
- jni/mips (don´t know)
- jni/mips64 (don´t know)

I can not help you finding out which is badly needed for you and which not.
 
Upvote 0

DonManfred

Expert
Licensed User
Longtime User
Upvote 0

Marco Nissen

Active Member
Licensed User
Longtime User
Thanks - now it's 114 seconds instead of 153
However, it looks like there's a systematic dependency of large files like this one, and the ARM architecture,
because I think the B4A app itself is running via the rosetta emulator .. I guess if B4A could be compiled for ARM then it would perform better?
or at least the copying process
 
Upvote 0
Top