search

dotnet / android

.NET for Android provides open-source bindings of the Android SDK for use with .NET managed languages such as C#
MIT License
1.93k stars 527 forks source link

Resolving Offset Errors in MAUI 8 Apps Post-Publisher Signing #9213

Closed zuo99 closed 1 month ago

zuo99 commented 2 months ago

Description

We are encountering a major issue with MAUI 8 apps. When the APK is handed over to the publisher, the signing process disrupts the alignment. During installation (signature verification) and running the app, we encounter an offset error with the assemblies/assemblies.blob file in the APK.

Since it's impractical to influence the publisher's release process and realign the APK each time, we need a solution that allows the app to run normally without re-aligning and re-signing the APK.

Steps to Reproduce

No response

Link to public reproduction project repository

No response

Version with bug

8.0.71 SR7.1

Is this a regression from previous behavior?

Yes, this used to work in .NET MAUI

Last version that worked well

8.0.71 SR7.1

Affected platforms

Android

Affected platform versions

No response

Did you find any workaround?

no

Relevant log output

No response

github-actions[bot] commented 2 months ago

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!

Closed similar issues:

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

jfversluis commented 2 months ago

I'm sorry but I think based of just this description it will be very hard to determine what is going on. How do you generate your APK? What are you seeing in terms of it not being aligned? What steps do you need to take to make it work? Do you have any log output? Error messages?

Without this information it will be near impossible to determine what might be going on and the chances of us resolving this will be almost none.

zuo99 commented 2 months ago

I'm sorry but I think based of just this description it will be very hard to determine what is going on. How do you generate your APK? What are you seeing in terms of it not being aligned? What steps do you need to take to make it work? Do you have any log output? Error messages?

Without this information it will be near impossible to determine what might be going on and the chances of us resolving this will be almost none. log 。。。。 F/monodroid-assembly( 4533): Assembly 'assemblies/assemblies.blob' is located at bad offset 9178401 within the .apk F/monodroid-assembly( 4533): You MUST run zipalign on base.apk --------- beginning of crash F/libc ( 4533): Fatal signal 6 (SIGABRT), code -6 in tid 4533 (csg.fd.mauipos) I/libc ( 4533): Suppressing debuggerd output because prctl(PR_GET_DUMPABLE)==0 I/Zygote ( 292): Process 4533 exited due to signal (6) I/ActivityManager( 792): Process csg.fd.mauipos (pid 4533) has died D/ActivityManager( 792): cleanUpApplicationRecord -- 4533

jfversluis commented 2 months ago

Thank you for the log output, this is indeed the result. Can you please tell us more about how you create your releases?

zuo99 commented 2 months ago

Thank you for the log output, this is indeed the result. Can you please tell us more about how you create your releases?

When releasing the application, I noticed that the system performs a signature operation. Before signing, the system also performs an alignment operation。

apk True my-key-alias 123456 123456 库拉索服务平台 1.0.5 False False portable True True False 512 True False

net8.0-android 
<!-- Uncomment to also build the tizen app. You will need to install tizen by following this: https://github.com/Samsung/Tizen.NET -->
<!-- <TargetFrameworks>$(TargetFrameworks);net7.0-tizen</TargetFrameworks> -->
<OutputType>Exe</OutputType>
<RootNamespace>Csg.Fd.MauiPOS</RootNamespace>
<UseMaui>true</UseMaui>
<SingleProject>true</SingleProject>
<ImplicitUsings>enable</ImplicitUsings>

<!-- Display name -->
<ApplicationTitle>Csg.MauiPOS</ApplicationTitle>

<!-- App Identifier -->
<ApplicationId>csg.fd.mauipos</ApplicationId>
<ApplicationIdGuid>4968d22c-6237-4e06-8f27-173b6cdf06d0</ApplicationIdGuid>

<!-- Versions -->
<ApplicationDisplayVersion>1.0.5</ApplicationDisplayVersion>
<ApplicationVersion>105</ApplicationVersion>

<SupportedOSPlatformVersion Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'android'">22.0</SupportedOSPlatformVersion>
<!--<SupportedOSPlatformVersion Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'ios'">11.0</SupportedOSPlatformVersion>
<SupportedOSPlatformVersion Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'maccatalyst'">13.1</SupportedOSPlatformVersion>
<SupportedOSPlatformVersion Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'android'">21.0</SupportedOSPlatformVersion>
<SupportedOSPlatformVersion Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'windows'">10.0.17763.0</SupportedOSPlatformVersion>
<TargetPlatformMinVersion Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'windows'">10.0.17763.0</TargetPlatformMinVersion>
<SupportedOSPlatformVersion Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'tizen'">6.5</SupportedOSPlatformVersion>-->
<AndroidSigningKeyStore>my-release-key-new.jks</AndroidSigningKeyStore>
<PackageIcon>apppak.png</PackageIcon>
<Nullable>disable</Nullable>
<!--<PublishTrimmed>True</PublishTrimmed>-->
<!--<Platforms>AnyCPU;ARM64</Platforms>     
<PlatformTarget>AnyCPU</PlatformTarget>-->

<!--<RuntimeIdentifiers>android-arm</RuntimeIdentifiers>
<PublishTrimmed>True</PublishTrimmed>
<RunAOTCompilation>False</RunAOTCompilation>
<AllowUnsafeBlocks>False</AllowUnsafeBlocks>-->

Additionally, it's worth mentioning that the customer's release platform can cause APK misalignment when releasing native Android apps, but this doesn't affect the functionality of the native APK. However, for some reason, this issue has a significant impact on MAUI. My APK development is complete, but I haven't been able to release it due to this problem, which is quite frustrating

zuo99 commented 2 months ago

I'm sorry but I think based of just this description it will be very hard to determine what is going on. How do you generate your APK? What are you seeing in terms of it not being aligned? What steps do you need to take to make it work? Do you have any log output? Error messages?

Without this information it will be near impossible to determine what might be going on and the chances of us resolving this will be almost none. How do you generate your APK?---A normal release process includes alignment and signing steps. The APK generated from this release, when installed on the test device, works perfectly fine. What are you seeing in terms of it not being aligned?--I received the APK released by the customer and conducted some tests. Upon checking the alignment of this APK, I found that it was not aligned. When this unaligned APK was installed on the test device, it resulted in errors. However, after aligning the APK and installing it on the test device, it ran successfully and functioned correctly. Unfortunately, I cannot intervene in the customer's release and installation certification process, so I can only run tests to identify the cause.

jfversluis commented 2 months ago

@jonathanpeppers does this mean anything to you?

dona2009 commented 2 months ago

hello,I concered the same question too, wish solution ,thanks.

jonathanpeppers commented 2 months ago

When the APK is handed over to the publisher, the signing process disrupts the alignment. During installation (signature verification) and running the app

What happens here exactly? Do they re-sign with apksigner, do they run zipalign?

we encounter an offset error with the assemblies/assemblies.blob file in the APK.

Ok, what is the error?

One thing that could break assemblies.blob, is if the file is compressed. We set it up to remain uncompressed, so it can be mmap-ed directly. Can you share the .apk file in question? If not, can you share the output of what 7z l displays for it?

This behavior also changed quite a bit in .NET 9, as assemblies.blob has moved to become a lib/*.so file -- so Android just sees it as a native library. Does .NET 9 work any differently?

There is not a lot of information go on here, can you give more details?

zuo99 commented 2 months ago

When the APK is handed over to the publisher, the signing process disrupts the alignment. During installation (signature verification) and running the app

What happens here exactly? Do they re-sign with apksigner, do they run zipalign?

we encounter an offset error with the assemblies/assemblies.blob file in the APK.

Ok, what is the error?

One thing that could break assemblies.blob, is if the file is compressed. We set it up to remain uncompressed, so it can be mmap-ed directly. Can you share the .apk file in question? If not, can you share the output of what 7z l displays for it?

This behavior also changed quite a bit in .NET 9, as assemblies.blob has moved to become a lib/*.so file -- so Android just sees it as a native library. Does .NET 9 work any differently?

There is not a lot of information go on here, can you give more details?

Our client, who is also the publisher, uses their own algorithm for re-signing the APK instead of using apksigner. After publishing, the signature verification on the POS device is also done using their custom algorithm. I can share both the APK I released and the one released by the client, but where should I share them? Do you think .NET 9 can solve this issue? If so, I can upgrade to .NET 9 as well.

jonathanpeppers commented 2 months ago

The files might be over 10MB for GitHub, so if you are ok to share a link to OneDrive, DropBox, etc. that is fine.

.NET 9 is just different, so it might work.

zuo99 commented 2 months ago

https://1drv.ms/u/c/ce49d5365a464840/ERtgpquBVjtIrD0n9hQzeucBbXEom34J7w-A0TReUWdtAA?e=bH1WkJ

Would using OneDrive work for sharing the files? There are three files: 105.apk is the APK after the client re-signed it, csg.fd.mauipos.apk is the original APK, and 3.txt is the log from running 105.apk.

jonathanpeppers commented 2 months ago

Are you able to share the error message?

zuo99 commented 2 months ago

Are you able to share the error message? Thank you very much. Below are some excerpts from the log： I/DEBUG ( 273): I/DEBUG ( 273): Build fingerprint: 'Verifone/msm8909/msm8909:5.1.1/LMY47V/linbx12122043:user/release-keys' I/DEBUG ( 273): Revision: '0' I/DEBUG ( 273): ABI: 'arm' I/DEBUG ( 273): pid: 9743, tid: 9743, name: csg.fd.mauipos >>> csg.fd.mauipos <<< I/DEBUG ( 273): signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr -------- I/DEBUG ( 273): Abort message: 'Assembly 'assemblies/assemblies.blob' is located at bad offset 9166419 within the .apk I/DEBUG ( 273): ' I/DEBUG ( 273): r0 00000000 r1 0000260f r2 00000006 r3 00000000 I/DEBUG ( 273): r4 b6f80e38 r5 00000006 r6 00000011 r7 0000010c I/DEBUG ( 273): r8 beeca12c r9 a1836be8 sl beeca138 fp 00000000 I/DEBUG ( 273): ip 0000260f sp beeca050 lr b6e0eac9 pc b6e35280 cpsr 600f0010 I/DEBUG ( 273): I/DEBUG ( 273): backtrace: I/DEBUG ( 273): #00 pc 0003a280 /system/lib/libc.so (tgkill+12) I/DEBUG ( 273): dotnet/maui#1 pc 00013ac5 /system/lib/libc.so (pthread_kill+52) I/DEBUG ( 273): dotnet/maui#2 pc 000146db /system/lib/libc.so (raise+10) I/DEBUG ( 273): dotnet/maui#3 pc 00010e7d /system/lib/libc.so (__libc_android_abort+36) I/DEBUG ( 273): dotnet/maui#4 pc 0000f534 /system/lib/libc.so (abort+4) I/DEBUG ( 273): dotnet/maui#5 pc 00015fbd /data/app/csg.fd.mauipos-1/lib/arm/libmonodroid.so (_ZN7xamarin7android7Helpers17abort_applicationEv+4) I/DEBUG ( 273): dotnet/maui#6 pc 000156ef /data/app/csg.fd.mauipos-1/lib/arm/libmonodroid.so (_ZN7xamarin7android8internal18EmbeddedAssemblies16zip_load_entriesEiPKcPFbS4_E+2462) I/DEBUG ( 273): dotnet/maui#7 pc 00014b0d /data/app/csg.fd.mauipos-1/lib/arm/libmonodroid.so (_ZN7xamarin7android8internal18EmbeddedAssemblies13register_fromEPKcPFbS4_E+68) I/DEBUG ( 273): dotnet/maui#8 pc 00017f35 /data/app/csg.fd.mauipos-1/lib/arm/libmonodroid.so (_ZN7xamarin7android8internal16MonodroidRuntime25gather_bundled_assembliesERNS0_21jstring_array_wrapperEPjb+68) I/DEBUG ( 273): dotnet/maui#9 pc 000170ad /data/app/csg.fd.mauipos-1/lib/arm/libmonodroid.so (_ZN7xamarin7android8internal16MonodroidRuntime13create_domainEP7_JNIEnvRNS0_21jstring_array_wrapperEbb+40) I/DEBUG ( 273): dotnet/maui#10 pc 000198df /data/app/csg.fd.mauipos-1/lib/arm/libmonodroid.so (_ZN7xamarin7android8internal16MonodroidRuntime28create_and_initialize_domainEP7_JNIEnvP7_jclassRNS0_21jstring_array_wrapperES8_P13_jobjectArrayS8_P8_jobjectbbb+26) I/DEBUG ( 273): dotnet/maui#11 pc 0001c0d9 /data/app/csg.fd.mauipos-1/lib/arm/libmonodroid.so (_ZN7xamarin7android8internal16MonodroidRuntime38Java_mono_android_Runtime_initInternalEP7_JNIEnvP7_jclassP8_jstringP13_jobjectArrayS8_SA_iP8_jobjectSA_ihh+2820) I/DEBUG ( 273): dotnet/maui#12 pc 0001e4e9 /data/app/csg.fd.mauipos-1/lib/arm/libmonodroid.so (Java_mono_android_Runtime_initInternal+52) I/DEBUG ( 273): dotnet/maui#13 pc 00a34083 /data/dalvik-cache/arm/data@app@csg.fd.mauipos-1@base.apk@classes.dex W/ActivityManager( 798): Force finishing activity 1 csg.fd.mauipos/crc64e6e2d214e60bf4e2.MainActivity I/DEBUG ( 273): I/DEBUG ( 273): Tombstone written to: /data/tombstones/tombstone_00 I/BootReceiver( 798): Copying /data/tombstones/tombstone_00 to DropBox (SYSTEM_TOMBSTONE) V/WLAN_PSA( 283): NL MSG, len[4036], NL type[0x1C] WNI type[0x5900] len[44047] V/WLAN_PSA( 283): NL MSG, PID: 283 I/Zygote ( 291): Process 9743 exited due to signal (6) I/WindowManager( 798): Screenshot max retries 4 of Token{39c7f489 ActivityRecord{2ad5e390 u0 csg.fd.mauipos/crc64e6e2d214e60bf4e2.MainActivity t817 f}} appWin=Window{f2cabc1 u0 Starting csg.fd.mauipos} drawState=4 W/ActivityManager( 798): Exception thrown during pause

jonathanpeppers commented 2 months ago

@zuo99 if you are getting here:

https://github.com/dotnet/android/blob/99ba8135fc47358702a5918757651d53d7b6fabd/src/native/monodroid/embedded-assemblies-zip.cc#L63

I believe this means they did not zipalign after re-signing the .apk.

/cc @grendello (but I think he's away for a bit)

zuo99 commented 2 months ago

@zuo99 if you are getting here:

https://github.com/dotnet/android/blob/99ba8135fc47358702a5918757651d53d7b6fabd/src/native/monodroid/embedded-assemblies-zip.cc#L63

I believe this means they did not zipalign after re-signing the .apk.

/cc @grendello (but I think he's away for a bit)

Yes, the client's publishing platform has always been running native Android applications, so they use their own signing and verification algorithms, which do not include alignment. The client has been running native Android applications without any issues, and they do not intend to change their signing and verification algorithms

grendello commented 2 months ago

@zuo99 if you are getting here: https://github.com/dotnet/android/blob/99ba8135fc47358702a5918757651d53d7b6fabd/src/native/monodroid/embedded-assemblies-zip.cc#L63

I believe this means they did not zipalign after re-signing the .apk. /cc @grendello (but I think he's away for a bit)

Yes, the client's publishing platform has always been running native Android applications, so they use their own signing and verification algorithms, which do not include alignment. The client has been running native Android applications without any issues, and they do not intend to change their signing and verification algorithms

@zuo99 Google requires all the content in the lib/ directory inside the APK to be aligned to the native page boundary (currently 4k, soon they will require 16k alignment), the requirement isn't unique to .NET for Android apps. Consider a note from this document:

Caution: You must use zipalign at a specific point in the build process. That point depends on which app-signing tool you use:

    If you use [apksigner](https://developer.android.com/studio/command-line/apksigner), zipalign must be used before the APK file has been signed. If you sign your APK using apksigner and make further changes to the APK, its signature is invalidated.
    If you use [jarsigner](https://docs.oracle.com/javase/tutorial/deployment/jar/signing.html) (not recommended), zipalign must be used after the APK file has been signed.

If your customer's applications happen to not have any shared libraries, just pure Kotlin/Java code then it may work by chance, but they will fail to work as soon as any native shared library is added.

Please take a look at this document as well, it discusses the upcoming requirement for 16k alignment.

We require the alignment as well because we use the mmap system call which needs the content to be at the page boundary as well. This is related to performance and it will not change. If your customer isn't willing to change their (broken, I'm afraid) signing process, your only option is to stop using assembly stores (set the AndroidUseAssemblyStore MSBuild property to false in your project file) and force extraction of all the lib/ content to device storage (set the application element's android:extractNativeLibs attribute to true in your AndroidManifest.xml file)

jonpryor commented 2 months ago

Dropping by to note that the alignment check was added in 2012-Jan-30, with helpful comment:

Assemblies need to be aligned on a 4-byte boundary, or Weird Things happen -- exception handlers are ignored, catch blocks not executed, random aborts, WebClient not downloading data -- and this can easily catch the unwary who sign their applications themselves and forget to zipalign the resulting package.

Verify that the mmap'd assemblies are on a valid boundary; if the validation fails, an error will be reported to logcat:

F/monodroid-assembly(12271): Assembly 'assemblies/Hello.dll' is located at a bad address 0x46ac6341 F/monodroid-assembly(12271): You MUST run zipalign on Mono.Samples.HelloTests-1.apk I/ActivityManager( 100): Process Mono.Samples.HelloTests (pid 12271) has died. D/Zygote ( 67): Process 12271 exited cleanly (90)

If you or your client's publishing platform hasn't hit this before, it's either because they have been running zipalign, or you have been very, very, lucky. This is not a recent change.

dona2009 commented 2 months ago

thanks ,we will config the above info firstly

zuo99 commented 2 months ago

@grendello @jonpryor thanks ， Our client has been using this platform for over a decade, and it has been running stably throughout. We have tried to encourage them to modify the signing and verification processes in the past, but unfortunately, they were unable to make the changes. I will now test the modification method you provided to see if it works. Thank you so much for your help。

（your only option is to stop using assembly stores (set the AndroidUseAssemblyStore MSBuild property to false in your project file) and force extraction of all the lib/ content to device storage (set the application element's android:extractNativeLibs attribute to true in your AndroidManifest.xml file)）

zuo99 commented 2 months ago

After testing with the above method, the error still occurs. The error message is as follows.log I/SurfaceFlinger( 263): FPS: 21 I/DEBUG ( 271): I/DEBUG ( 271): Build fingerprint: 'Verifone/msm8909/msm8909:5.1.1/LMY47V/linbx12122043:user/release-keys' I/DEBUG ( 271): Revision: '0' I/DEBUG ( 271): ABI: 'arm' I/DEBUG ( 271): pid: 8974, tid: 8974, name: csg.fd.mauipos >>> csg.fd.mauipos <<< I/DEBUG ( 271): signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr -------- I/DEBUG ( 271): Abort message: 'Assembly 'assemblies/ar/Microsoft.Maui.Controls.resources.dll' is located at bad offset 9257022 within the .apk I/DEBUG ( 271): ' I/DEBUG ( 271): r0 00000000 r1 0000230e r2 00000006 r3 00000000 I/DEBUG ( 271): r4 b6f7de38 r5 00000006 r6 00000011 r7 0000010c I/DEBUG ( 271): r8 beb8e138 r9 0000044e sl beb8e138 fp beb8e0e4 I/DEBUG ( 271): ip 0000230e sp beb8e050 lr b6e0bac9 pc b6e32280 cpsr 600f0010 I/DEBUG ( 271): I/DEBUG ( 271): backtrace: I/DEBUG ( 271): #00 pc 0003a280 /system/lib/libc.so (tgkill+12) I/DEBUG ( 271): #01 pc 00013ac5 /system/lib/libc.so (pthread_kill+52) I/DEBUG ( 271): #02 pc 000146db /system/lib/libc.so (raise+10) I/DEBUG ( 271): #03 pc 00010e7d /system/lib/libc.so (__libc_android_abort+36) I/DEBUG ( 271): #04 pc 0000f534 /system/lib/libc.so (abort+4) I/DEBUG ( 271): #05 pc 00015fbd /data/app/csg.fd.mauipos-2/lib/arm/libmonodroid.so (_ZN7xamarin7android7Helpers17abort_applicationEv+4) I/DEBUG ( 271): #06 pc 000156ef /data/app/csg.fd.mauipos-2/lib/arm/libmonodroid.so (_ZN7xamarin7android8internal18EmbeddedAssemblies16zip_load_entriesEiPKcPFbS4_E+2462) I/DEBUG ( 271): #07 pc 00014b0d /data/app/csg.fd.mauipos-2/lib/arm/libmonodroid.so (_ZN7xamarin7android8internal18EmbeddedAssemblies13register_fromEPKcPFbS4_E+68) I/DEBUG ( 271): #08 pc 00017f35 /data/app/csg.fd.mauipos-2/lib/arm/libmonodroid.so (_ZN7xamarin7android8internal16MonodroidRuntime25gather_bundled_assembliesERNS0_21jstring_array_wrapperEPjb+68) I/DEBUG ( 271): #09 pc 000170ad /data/app/csg.fd.mauipos-2/lib/arm/libmonodroid.so (_ZN7xamarin7android8internal16MonodroidRuntime13create_domainEP7_JNIEnvRNS0_21jstring_array_wrapperEbb+40) I/DEBUG ( 271): #10 pc 000198df /data/app/csg.fd.mauipos-2/lib/arm/libmonodroid.so (_ZN7xamarin7android8internal16MonodroidRuntime28create_and_initialize_domainEP7_JNIEnvP7_jclassRNS0_21jstring_array_wrapperES8_P13_jobjectArrayS8_P8_jobjectbbb+26) I/DEBUG ( 271): #11 pc 0001c0d9 /data/app/csg.fd.mauipos-2/lib/arm/libmonodroid.so (_ZN7xamarin7android8internal16MonodroidRuntime38Java_mono_android_Runtime_initInternalEP7_JNIEnvP7_jclassP8_jstringP13_jobjectArrayS8_SA_iP8_jobjectSA_ihh+2820) I/DEBUG ( 271): #12 pc 0001e4e9 /data/app/csg.fd.mauipos-2/lib/arm/libmonodroid.so (Java_mono_android_Runtime_initInternal+52) I/DEBUG ( 271): #13 pc 00a3c7bb /data/dalvik-cache/arm/data@app@csg.fd.mauipos-2@base.apk@classes.dex D/StatusBar.NetworkController( 2605): refreshViews: Data not connected!! Set no data type icon / Roaming I/DEBUG ( 271): I/DEBUG ( 271): Tombstone written to: /data/tombstones/tombstone_07 I/BootReceiver( 798): Copying /data/tombstones/tombstone_07 to DropBox (SYSTEM_TOMBSTONE) W/ActivityManager( 798): Force finishing activity 1 csg.fd.mauipos/crc64e6e2d214e60bf4e2.MainActivity I/Zygote ( 291): Process 8974 exited due to signal (6) I/WindowManager( 798): Screenshot max retries 4 of Token{1a04b32d ActivityRecord{2251a644 u0 csg.fd.mauipos/crc64e6e2d214e60bf4e2.MainActivity t869 f}} appWin=Window{a0657c8 u0 Starting csg.fd.mauipos} drawState=4 W/ActivityManager( 798): Exception thrown during pause W/ActivityManager( 798): android.os.DeadObjectException W/ActivityManager( 798): at android.os.BinderProxy.transactNative(Native Method) W/ActivityManager( 798): at android.os.BinderProxy.transact(Binder.java:496) W/ActivityManager( 798): at android.app.ApplicationThreadProxy.schedulePauseActivity(ApplicationThreadNative.java:704) W/ActivityManager( 798): at com.android.server.am.ActivityStack.startPausingLocked(ActivityStack.java:842) W/ActivityManager( 798): at com.android.server.am.ActivityStack.finishActivityLocked(ActivityStack.java:2757) W/ActivityManager( 798): at com.android.server.am.ActivityStack.finishTopRunningActivityLocked(ActivityStack.java:2614) W/ActivityManager( 798): at com.android.server.am.ActivityStackSupervisor.finishTopRunningActivityLocked(ActivityStackSupervisor.java:2540) W/ActivityManager( 798): at com.android.server.am.ActivityManagerService.handleAppCrashLocked(ActivityManagerService.java:11672) W/ActivityManager( 798): at com.android.server.am.ActivityManagerService.makeAppCrashingLocked(ActivityManagerService.java:11569) W/ActivityManager( 798): at com.android.server.am.ActivityManagerService.crashApplication(ActivityManagerService.java:12255) W/ActivityManager( 798): at com.android.server.am.ActivityManagerService.handleApplicationCrashInner(ActivityManagerService.java:11766) W/ActivityManager( 798): at com.android.server.am.NativeCrashListener$NativeCrashReporter.run(NativeCrashListener.java:86) E/lowmemorykiller( 260): Error opening /proc/8974/oom_score_adj; errno=2 I/ActivityManager( 798): Process csg.fd.mauipos (pid 8974) has died D/ActivityManager( 798): cleanUpApplicationRecord -- 8974 E/WindowState( 798): getStack: Window{a0657c8 u0 Starting csg.fd.mauipos} couldn't find taskId=869 Callers=com.android.server.wm.WindowState.getDisplayContent:789

grendello commented 2 months ago

@zuo99 I'm sorry, but there's nothing more we can do. Refer to this comment to see why assemblies inside the apk must be aligned (and there's no way to extract them to the filesystem at application install time). The technical reality is that the entries must be aligned inside the APK. Your customer is the only one that can fix the issue, as it's their process that breaks the documented and required invariants we (and the entire Android ecosystem) rely upon.

zuo99 commented 2 months ago

This is a sad story. We've spent about six months developing this app, and if we can't launch it, we'll have to switch to developing a native Android app. Is it possible to, after client signing and verification, capture the installation package to the current directory when the program starts, perform alignment, and then use this aligned program in the future?

zuo99 commented 2 months ago

We don't want to give up. There must be a way to make it work.

dona2009 commented 2 months ago

Fighting !

grendello commented 2 months ago

@zuo99 the .NET9 release of .NET for Android (which is what MAUI uses to run on Android) moves all assemblies to the lib/ folder inside the APK archive, that means everything there can be extracted to the filesystem (after setting the android:extractNativeLibs=true attribute as described previously) and then your app should work with the broken signing system.

grendello commented 2 months ago

This is a sad story. We've spent about six months developing this app, and if we can't launch it, we'll have to switch to developing a native Android app. Is it possible to, after client signing and verification, capture the installation package to the current directory when the program starts, perform alignment, and then use this aligned program in the future?

Switching to a "native" Android app won't help you if you use any native libraries in your apps (e.g. Skia, but anything really). You can re-align an already signed package, as long as you don't make any other changes to its contents (it would invalidate the signature). If you can do it yourselves, then by all means do it :)

The real fix here (and the only needed one) is to make your customer fix their buggy signing process and just run zipalign after signing... I find it really hard to understand why they are so reluctant to perform a step that's documented as required by Google.

Note that while the contents of the lib/ directory is the main place where alignment matters, it's not the only one. Essentially, if you look at your APK you will notice that some of the entries aren't compressed (assets, some graphics files, resources etc) - those are the files Android wants to mmap and they are present in "native" applications as well. The objective Google had here was to decrease space usage of applications. Instead of uncompressing everything from the apk, only portions of it are uncompressed to the filesystem, the rest is mmapped directly from the apk.

I don't know what version of Android the POS device you mentioned uses, it's possible it's a very old one (pre API-23, that's Android 6.0) which didn't have that requirement (but would still work just fine with aligned APKs) and that makes it to work by chance. Upgrade to any newer version of Android would then break the misaligned apps in a similar way you're observing here.

zuo99 commented 1 month ago

@grendello Thank you so much for the detailed explanation. Your insights are spot on. The current app is designed for Android 5.1, and the client’s signing and verification process is also on 5.1. It seems that there are various reasons why the client won’t modify the signing process, which we can't change.

As you mentioned, if the app goes beyond Android 6, even a native app might face issues. This means I can wait, as the client plans to upgrade to Android 8. At that point, they might encounter the signing verification issue and will need to find a solution.

Also, I'll try running it on .NET 9 since you mentioned it might work fine.

Thanks again for your help!

zuo99 commented 1 month ago

android/src/native/monodroid/embedded-assemblies-zip.cc

Line 63 in 99ba813

if (((state.data_offset & 0xf) != 0) || ((state.data_offset & 0x3) != 0)) {

Running the app on Android versions below 6.0 might work without verifying alignment. You could provide an option to skip alignment verification, as Google initially did not enforce this requirement。

grendello commented 1 month ago

@zuo99 we can't - we require the assembly entries to be aligned, no matter what's the Android version. See this comment for more info.

zuo99 commented 1 month ago

@zuo99 we can't - we require the assembly entries to be aligned, no matter what's the Android version. See this comment for more info.

ok.