Google Play New problem : 64bits
Moderator: Moderators
Re: Google Play New problem : 64bits
The "fixes_3_2" branch compiles just fine. Unfortunately, it gives this error right away when building ZGE:
jni.pas(543) Error: Assembler aarch64-linux-android-as.exe not found, switching to external assembling
So I thought that maybe they updated their compiler to be able to use a more recent NDK than r21e, but I recalled that aarch64-linux-android-as.exe does not exist after that NDK.
So I added this PATH in my building script:
PATH=C:\Android\android-ndk-r21e\toolchains\llvm\prebuilt\windows-x86_64\bin;
And the next error is:
ZPlatform_Android.inc(63,59) Fatal: Can't find unit SyncObjs used by ZPlatform
SyncObjs is located in C:\FPC\trunk_3_2\units\aarch64-android\fcl-base for 64bits so I added it as a -Fu
call %FPC_PATH%\ppcrossa64 -B -MDelphi -Sghi -O3 -Tandroid -Paarch64 -XXis -vw -Filib\arm64-v8a -Fl%NDK_PATH%\arch-arm64\usr\lib -Fu. -Fu..\.. -FuC:\FPC\trunk_3_2\units\aarch64-android\fcl-base -FUobj\arm64-v8a\ -FEjava\libs\arm64-v8a\ -olibzgeandroid.so -dANDROID -dMINIMAL -Xd -CpARMV8 %DEBUG_FLAG% zgeandroid.pas
And it builds just fine. But the result is the same. Threads are killing the app after a few frames...
No different error message either.
jni.pas(543) Error: Assembler aarch64-linux-android-as.exe not found, switching to external assembling
So I thought that maybe they updated their compiler to be able to use a more recent NDK than r21e, but I recalled that aarch64-linux-android-as.exe does not exist after that NDK.
So I added this PATH in my building script:
PATH=C:\Android\android-ndk-r21e\toolchains\llvm\prebuilt\windows-x86_64\bin;
And the next error is:
ZPlatform_Android.inc(63,59) Fatal: Can't find unit SyncObjs used by ZPlatform
SyncObjs is located in C:\FPC\trunk_3_2\units\aarch64-android\fcl-base for 64bits so I added it as a -Fu
call %FPC_PATH%\ppcrossa64 -B -MDelphi -Sghi -O3 -Tandroid -Paarch64 -XXis -vw -Filib\arm64-v8a -Fl%NDK_PATH%\arch-arm64\usr\lib -Fu. -Fu..\.. -FuC:\FPC\trunk_3_2\units\aarch64-android\fcl-base -FUobj\arm64-v8a\ -FEjava\libs\arm64-v8a\ -olibzgeandroid.so -dANDROID -dMINIMAL -Xd -CpARMV8 %DEBUG_FLAG% zgeandroid.pas
And it builds just fine. But the result is the same. Threads are killing the app after a few frames...
No different error message either.
Re: Google Play New problem : 64bits
Maybe the makefile from fixes_3_2 can be copied to trunk and build it that way.
What NDK version are you using now?
What NDK version are you using now?
Re: Google Play New problem : 64bits
Using fixes_3_2 makefile in trunk doesn't solve anything. I'm going to create a topic on freepascal's forum regarding the compilation of crosscompiler for Android from Windows.
As for the Android NDK, I'm using the old r21e. That is the only one that works.
I already spent days trying to run a slightly more recent version, that still has the exe needed by fpc, but in a slightly different form: https://www.emix8.org/forum/viewtopic.p ... 767#p10767
And I also tried to build and to link the libzgeandroid.so manually. The resulted library is totally broken.
https://www.emix8.org/forum/viewtopic.p ... 803#p10803
As for the Android NDK, I'm using the old r21e. That is the only one that works.
I already spent days trying to run a slightly more recent version, that still has the exe needed by fpc, but in a slightly different form: https://www.emix8.org/forum/viewtopic.p ... 767#p10767
And I also tried to build and to link the libzgeandroid.so manually. The resulted library is totally broken.
https://www.emix8.org/forum/viewtopic.p ... 803#p10803
Last edited by Ats on Mon Oct 14, 2024 2:57 pm, edited 1 time in total.
Re: Google Play New problem : 64bits
Something I don't think we have tried yet. In zgeandroid.pas (not zzdc.dpr), try this uses order:
Code: Select all
uses
cmem,
cthreads,
jni,
ZOpenGL,
Re: Google Play New problem : 64bits
hahaha, imagine if the fix was that easy...
...
And it is.
Omeganaut is running perfectly fine with threads and sound on Android 64 WELL DONE!
Now I need to clean things up. I'm going to build libzgeandroid.so with just that last change in ZgeAndroid.pas and see if everything is working. Or if we really need the changes on the JNI calls in ZPlatform_Android.inc
...
And it is.
Omeganaut is running perfectly fine with threads and sound on Android 64 WELL DONE!
Now I need to clean things up. I'm going to build libzgeandroid.so with just that last change in ZgeAndroid.pas and see if everything is working. Or if we really need the changes on the JNI calls in ZPlatform_Android.inc
Last edited by Ats on Tue Oct 15, 2024 8:33 am, edited 2 times in total.
Re: Google Play New problem : 64bits
I wish I thought of this sooner. I forgot that ZzDC.dpr is not used for Android builds. Sorry for letting you go through all that trouble.
Re: Google Play New problem : 64bits
Good to see that the culprit was finally found!
K
Re: Google Play New problem : 64bits
Modifying only ZgeAndroid.pas isn't sufficient.
Here's all the changes we made. I removed the ones on ZzDC.dpr
Those two changes are necessary for threads to work:
In ZgeAndroid.pas :
In ZPlatform_Android.pas / function Platform_GetCpuCount:
replace
by
But with only those changes, the audio is still crashing.
So here are the changes we made for the audio:
In jni.pas:
Replace
by
In ZPlatform_Android.inc / function AudioCallback
Replace
by
replace
by
replace
by
replace
by
replace
by
replace
by
replace
by
With all those changes, I fixed the audio from the fresh git code. But should we keep all those changes?
Edit:
I built the 32 bit version of libzgeandroid.so just to be sure it is still working with all those changes. Everything's fine!
Here's all the changes we made. I removed the ones on ZzDC.dpr
Those two changes are necessary for threads to work:
In ZgeAndroid.pas :
Code: Select all
uses
cmem,
cthreads,
jni,
ZOpenGL,
ZClasses,
replace
Code: Select all
RunObj := Env^.CallStaticObjectMethodV(Env, RunClass, Mid, nil);
Code: Select all
RunObj := Env^.CallStaticObjectMethod(Env, RunClass, Mid);
But with only those changes, the audio is still crashing.
So here are the changes we made for the audio:
In jni.pas:
Replace
Code: Select all
CallNonvirtualIntMethodV:function(Env:PJNIEnv;Obj:JObject;AClass:JClass;MethodID:JMethodID;Args:va_list):JInt;{$ifdef mswindows}stdcall;{$else}cdecl;{$endif}
Code: Select all
CallNonvirtualIntMethodV:function(Env:PJNIEnv;Obj:JObject;AClass:JClass;MethodID:JMethodID):JInt;{$ifdef mswindows}stdcall;{$else}cdecl;{$endif} varargs;
In ZPlatform_Android.inc / function AudioCallback
Replace
Code: Select all
{$IFDEF CPU64}
function AudioCallback(Data : pointer) : Int64;
{$ELSE}
function AudioCallback(P : pointer): LongInt;
{$ENDIF}
Code: Select all
{$IFDEF CPU64}
function AudioCallback(P: Pointer): Int64;
{$ELSE}
function AudioCallback(P : pointer): LongInt;
{$ENDIF}
Code: Select all
Params : array[0..10] of integer;
Code: Select all
Params : array[0..10] of JValue;
Code: Select all
function C(const args : array of const) : pointer;
var
I : integer;
begin
for I := 0 to High(args) do
Params[I] := args[I].vinteger;
Result := @Params;
end;
Code: Select all
function C(const args : array of const) : PJValue;
var
I : integer;
begin
Fillchar(Params, SizeOf(Params), 0);
for I := 0 to High(args) do
begin
case args[I].VType of
vtInteger: Params[I].i := args[I].VInteger; // Assign integer value
vtPointer: Params[I].l := args[I].VPointer; // Assign pointer value
else
raise Exception.Create('Unsupported argument type');
end;
end;
Result := @Params;
end;
Code: Select all
bufferSizeInBytes := Env^.CallStaticIntMethodV(env, cAudioTrack, mGetMinBufferSize, C([AudioPlayer.AudioRate, 3, 2]));
Code: Select all
bufferSizeInBytes := Env^.CallStaticIntMethodA(env, cAudioTrack, mGetMinBufferSize, C([AudioPlayer.AudioRate, 3, 12]));
Code: Select all
track := env^.NewObjectV(env, cAudioTrack, mAudioTrack, C([3, AudioPlayer.AudioRate, 3, 2, bufferSizeInBytes, 1]));
Code: Select all
track := env^.NewObjectA(env, cAudioTrack, mAudioTrack, C([3, AudioPlayer.AudioRate, 3, 2, bufferSizeInBytes, 1]));
Code: Select all
MixAndCopyData(PBuffer,OnePassSize);
Code: Select all
MixAndCopyData(PBuffer, Min(OnePassSize, bufferSizeInBytes));
Code: Select all
env^.CallNonvirtualIntMethodV(env, track, cAudioTrack, mWrite, C([buffer, 0, OnePassSize]));
Code: Select all
env^.CallNonvirtualIntMethodA(env, track, cAudioTrack, mWrite, C([buffer, 0, Min(OnePassSize, bufferSizeInBytes)]));
Edit:
I built the 32 bit version of libzgeandroid.so just to be sure it is still working with all those changes. Everything's fine!
Re: Google Play New problem : 64bits
Looks good, please send a pull request and I can make any final edits if needed.
Re: Google Play New problem : 64bits
It's done. Thanks for your help with this
Once everything will be verified and merge, can you make a new zip for ZGameEditor, so I can benefit from the android folder renamed to armeabi-v7a? Then I'll go on updating how the android Template works and add the recent libraries to it.
Once everything will be verified and merge, can you make a new zip for ZGameEditor, so I can benefit from the android folder renamed to armeabi-v7a? Then I'll go on updating how the android Template works and add the recent libraries to it.
Re: Google Play New problem : 64bits
Woops... There's another BRAND NEW problem that I didn't spot before...
Audio only works in debug mode, when the usb cable is plugged to the computer and the apk is launched using run.bat
If I launch the audio test in debug mode from the phone, with or without the cable, it instantaneously crashes.
It also crashes instantaneously in release mode.
This only happen when there is audio in the project.
I already built the libraries without the -g
And the AndroidManifest is set to android:debuggable="false"
Since running the app with the usb plugged in is way slower that the usual, can that affect the threads or something?
Audio only works in debug mode, when the usb cable is plugged to the computer and the apk is launched using run.bat
If I launch the audio test in debug mode from the phone, with or without the cable, it instantaneously crashes.
It also crashes instantaneously in release mode.
This only happen when there is audio in the project.
I already built the libraries without the -g
And the AndroidManifest is set to android:debuggable="false"
Since running the app with the usb plugged in is way slower that the usual, can that affect the threads or something?
Re: Google Play New problem : 64bits
Can you get logs from these crashes?
Re: Google Play New problem : 64bits
Yep. After reactivating debug:
That's on the pure 64bit phone. On the old one, sometime it is working, sometime not. Maybe because it is noticeably slower?
Code: Select all
********** Crash dump: **********
Build fingerprint: 'google/cheetah/cheetah:14/AP2A.240905.003/12231197:user/release-keys'
Abort message: 'Scudo ERROR: corrupted chunk header at address 0x20000732e8b77f0'
#00 0x000000000005d8e4 /apex/com.android.runtime/lib64/bionic/libc.so (abort+164) (BuildId: 1d36f8ae6e0af6158793abea7d4f4f2b)
#01 0x0000000000048d18 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::die()+8) (BuildId: 1d36f8ae6e0af6158793abea7d4f4f2b)
#02 0x00000000000499ec /apex/com.android.runtime/lib64/bionic/libc.so (scudo::reportRawError(char const*)+28) (BuildId: 1d36f8ae6e0af6158793abea7d4f4f2b)
#03 0x000000000004995c /apex/com.android.runtime/lib64/bionic/libc.so (scudo::ScopedErrorReport::~ScopedErrorReport()+12) (BuildId: 1d36f8ae6e0af6158793abea7d4f4f2b)
#04 0x0000000000049ac0 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::reportHeaderCorruption(void*)+96) (BuildId: 1d36f8ae6e0af6158793abea7d4f4f2b)
#05 0x000000000004bab4 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::Allocator<scudo::AndroidNormalConfig, &(scudo_malloc_postinit)>::deallocate(void*, scudo::Chunk::Origin, unsigned long, unsigned long)+276) (BuildId: 1d36f8ae6e0af6158793abea7d4f4f2b)
#06 0x000000000042e864 /system/lib64/libhwui.so (GrDirectContext::~GrDirectContext()+388) (BuildId: 40bb4b94e9a16adbb1371c4bfe55f94e)
#07 0x00000000006cf3e0 /system/lib64/libhwui.so (GrDirectContext::~GrDirectContext()+16) (BuildId: 40bb4b94e9a16adbb1371c4bfe55f94e)
#08 0x00000000002c1b48 /system/lib64/libhwui.so (android::uirenderer::renderthread::RenderThread::setGrContext(sk_sp<GrDirectContext>)+344) (BuildId: 40bb4b94e9a16adbb1371c4bfe55f94e)
#09 0x000000000040ffa0 /system/lib64/libhwui.so (android::uirenderer::renderthread::RenderThread::destroyRenderingContext()+64) (BuildId: 40bb4b94e9a16adbb1371c4bfe55f94e)
#10 0x000000000040f494 /system/lib64/libhwui.so (android::uirenderer::renderthread::CacheManager::trimMemory(android::uirenderer::TrimLevel)+260) (BuildId: 40bb4b94e9a16adbb1371c4bfe55f94e)
#11 0x000000000040f354 /system/lib64/libhwui.so (android::uirenderer::renderthread::RenderThread::trimMemory(android::uirenderer::TrimLevel)+36) (BuildId: 40bb4b94e9a16adbb1371c4bfe55f94e)
#12 0x00000000004c315c /system/lib64/libhwui.so (android::uirenderer::renderthread::RenderThread::threadLoop()+732) (BuildId: 40bb4b94e9a16adbb1371c4bfe55f94e)
#13 0x00000000000115d4 /system/lib64/libutils.so (android::Thread::_threadLoop(void*)+244) (BuildId: c07f08c7e5a964a8f8c6bc5c820fb795)
#14 0x000000000006efbc /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+204) (BuildId: 1d36f8ae6e0af6158793abea7d4f4f2b)
#15 0x0000000000060d60 /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId: 1d36f8ae6e0af6158793abea7d4f4f2b)
Crash dump is completed
Re: Google Play New problem : 64bits
That crash might have nothing to do with our problem. But I found how to fix that:
replacing
bufferSizeInBytes := Env^.CallStaticIntMethodA(env, cAudioTrack, mGetMinBufferSize, C([AudioPlayer.AudioRate, 3, 12]));
by
bufferSizeInBytes := Env^.CallStaticIntMethodA(env, cAudioTrack, mGetMinBufferSize, C([AudioPlayer.AudioRate, 3, 2]));
Pure luck on that one, only because I asked myself why the next
track := env^.NewObjectA(env, cAudioTrack, mAudioTrack, C([3, AudioPlayer.AudioRate, 3, 2, bufferSizeInBytes, 1]));
was 2 instead of 12.
I tried both 12, it crashes, even in adb debug mode.
And both 2, it works, even in release mode.
Does it make sense? I'm not sure
Edit:
In Omeganaut, in release mode, the sound can be EXTREMELY low-fi. The sound is low-fi, but this is way worse.
And debug or release mode, it crashes randomly while playing. I'm trying to get a log.
crash log isn't helping...
********** Crash dump: **********
Build fingerprint: 'google/cheetah/cheetah:14/AP2A.240905.003/12231197:user/release-keys'
#00 0x0000000000000004 <anonymous:74de5f6000>
Crash dump is completed
Edit:
Lastly, there are no problems with our changes in the code if I run the game in 32bit only on the old phone. The game is working perfectly. No crappy sounds, no crash.
replacing
bufferSizeInBytes := Env^.CallStaticIntMethodA(env, cAudioTrack, mGetMinBufferSize, C([AudioPlayer.AudioRate, 3, 12]));
by
bufferSizeInBytes := Env^.CallStaticIntMethodA(env, cAudioTrack, mGetMinBufferSize, C([AudioPlayer.AudioRate, 3, 2]));
Pure luck on that one, only because I asked myself why the next
track := env^.NewObjectA(env, cAudioTrack, mAudioTrack, C([3, AudioPlayer.AudioRate, 3, 2, bufferSizeInBytes, 1]));
was 2 instead of 12.
I tried both 12, it crashes, even in adb debug mode.
And both 2, it works, even in release mode.
Does it make sense? I'm not sure
Edit:
In Omeganaut, in release mode, the sound can be EXTREMELY low-fi. The sound is low-fi, but this is way worse.
And debug or release mode, it crashes randomly while playing. I'm trying to get a log.
crash log isn't helping...
********** Crash dump: **********
Build fingerprint: 'google/cheetah/cheetah:14/AP2A.240905.003/12231197:user/release-keys'
#00 0x0000000000000004 <anonymous:74de5f6000>
Crash dump is completed
Edit:
Lastly, there are no problems with our changes in the code if I run the game in 32bit only on the old phone. The game is working perfectly. No crappy sounds, no crash.
Re: Google Play New problem : 64bits
Ok it should be 2 I guess for stereo output. The documentation suggested 12 but if 2 works then we should keep that.