the android quit when I first run the APP in .net MAUI?

Question

the android quit when I first run the APP in .net MAUI?

mc 7,231

I am using .net MAUI 9.0 and when I first debug the APP will crash/quit in android.

and then I debug it runs well. and when I uninstall it and then debug again it will crash/quit again.

how to find the error of it? there is no exception

I run it on my mobile not emulator.

Mohsin Ali Shah 0 Reputation points

2026-08-03T17:27:43.9+00:00
Crash issues on the first launch of a .NET MAUI Android app—especially without throwing an exception in Visual Studio—are a common headache. This behavior, where it crashes initially but works on subsequent debug runs, often points to an issue with how the Android runtime handles the application's startup, view hierarchy, or native library loading.

Since you aren't seeing an exception in your IDE, you need to look at what the Android device itself is reporting.

Here is a step-by-step guide on how to diagnose and fix this problem.

1. Capture the Android Logcat

Because Visual Studio isn't catching the exception, you must read the device's system logs using Logcat. Logcat records everything happening on the Android device, including low-level runtime crashes that MAUI might miss.

1.Connect your device:

Ensure your mobile device is connected via USB and debugging is enabled.

2.Open the Android Device Log:

In Visual Studio, go to Tools > Android > Device Log.

3.Filter the logs:

In the Device Log window, filter by your app's package name or by the tag AndroidRuntime. You can also filter the severity to Error or Fatal.

4.Reproduce the crash:

Uninstall the app from your phone, clear the logs in the Device Log window, and start a new debugging session from Visual Studio to force the first-run crash.

5.Analyze the output:

Look for the stack trace immediately following the crash. It will usually point to the exact cause.

2. Common Culprits to Check

Based on common .NET MAUI issues, here are the most likely reasons for a first-launch crash:

The "Child Already Has a Parent" Error

If your Logcat shows an IllegalStateException: The specified child already has a parent, this is a known issue in UI logic.

The Cause: This happens when MAUI tries to add a view to the screen that is already attached elsewhere. It is frequently triggered by ObservableCollection updates in a CollectionView or custom templates reusing views. Android strictly enforces that a view can only have one parent.

The Fix: Ensure that each item creates a new view instance. If you are manipulating the view hierarchy directly, make sure old views are removed before re-adding them.

Missing Native Libraries (ABI Mismatch)

If Logcat shows an error like dlopen failed: library not found, the Android runtime is missing a required native library.

The Cause: Your build output might be corrupted, or the APK splits (if using App Bundles) are incomplete on the device.

The Fix:

Verify you are targeting the correct ABI for your phone (likely arm64-v8a) in your project settings.

Clean the solution (__Build__ -> __Clean Solution__) and rebuild. Ensure the app is completely deleted from the device before redeploying.

Architecture Bug in .NET 9

If your phone uses an older 32-bit ARM architecture (like the Samsung A13), there is a known bug when upgrading to .NET 9.

The Cause: .NET 9 changed how architectures are targeted, which can cause the debugger to crash specifically on arm-32 devices on the first launch.

The Fix: Ensure you are using the latest version of Visual Studio 2022 (17.13 or newer), as Microsoft has released a fix for this specific issue.

AOT Compilation and Trimming

While more common in Release builds, if you have modified your Debug configuration to mimic Release, Ahead-of-Time (AOT) compilation or code trimming might be stripping out necessary code during the build.

The Fix: Check your .csproj file and ensure that <PublishTrimmed> and <RunAOTCompilation> are set to false for your Debug configuration.

Crash issues on the first launch of a .NET MAUI Android app—especially without throwing an exception in Visual Studio—are a common headache. This behavior, where it crashes initially but works on subsequent debug runs, often points to an issue with how the Android runtime handles the application's startup, view hierarchy, or native library loading.

Since you aren't seeing an exception in your IDE, you need to look at what the Android device itself is reporting.

Here is a step-by-step guide on how to diagnose and fix this problem.

1. Capture the Android Logcat

Because Visual Studio isn't catching the exception, you must read the device's system logs using Logcat. Logcat records everything happening on the Android device, including low-level runtime crashes that MAUI might miss.

1.Connect your device:

Ensure your mobile device is connected via USB and debugging is enabled.

2.Open the Android Device Log:

In Visual Studio, go to Tools > Android > Device Log.

3.Filter the logs:

In the Device Log window, filter by your app's package name or by the tag AndroidRuntime. You can also filter the severity to Error or Fatal.

4.Reproduce the crash:

Uninstall the app from your phone, clear the logs in the Device Log window, and start a new debugging session from Visual Studio to force the first-run crash.

5.Analyze the output:

Look for the stack trace immediately following the crash. It will usually point to the exact cause.

2. Common Culprits to Check

Based on common .NET MAUI issues, here are the most likely reasons for a first-launch crash:

The "Child Already Has a Parent" Error

If your Logcat shows an IllegalStateException: The specified child already has a parent, this is a known issue in UI logic.

The Cause: This happens when MAUI tries to add a view to the screen that is already attached elsewhere. It is frequently triggered by ObservableCollection updates in a CollectionView or custom templates reusing views. Android strictly enforces that a view can only have one parent.

The Fix: Ensure that each item creates a new view instance. If you are manipulating the view hierarchy directly, make sure old views are removed before re-adding them.

Missing Native Libraries (ABI Mismatch)

If Logcat shows an error like dlopen failed: library not found, the Android runtime is missing a required native library.

The Cause: Your build output might be corrupted, or the APK splits (if using App Bundles) are incomplete on the device.

The Fix:

Verify you are targeting the correct ABI for your phone (likely arm64-v8a) in your project settings.

Clean the solution (__Build__ -> __Clean Solution__) and rebuild. Ensure the app is completely deleted from the device before redeploying.

Architecture Bug in .NET 9

If your phone uses an older 32-bit ARM architecture (like the Samsung A13), there is a known bug when upgrading to .NET 9.

The Cause: .NET 9 changed how architectures are targeted, which can cause the debugger to crash specifically on arm-32 devices on the first launch.

The Fix: Ensure you are using the latest version of Visual Studio 2022 (17.13 or newer), as Microsoft has released a fix for this specific issue.

AOT Compilation and Trimming

While more common in Release builds, if you have modified your Debug configuration to mimic Release, Ahead-of-Time (AOT) compilation or code trimming might be stripping out necessary code during the build.

The Fix: Check your .csproj file and ensure that <PublishTrimmed> and <RunAOTCompilation> are set to false for your Debug configuration.

Answer accepted by question author

Tony Thach (WICLOUD CORPORATION) 240 Microsoft External Staff Moderator

Hello @mc ,

Thanks for your question.

Based on the behavior you described, I would focus on the first-install / first-launch scenario as the primary clue.

Since the application crashes only after a fresh install and then runs normally on subsequent launches, I recommend capturing Android runtime logs rather than relying solely on the debugger output.

Startup exceptions do not always appear in the IDE, especially when they occur during Android initialization.

You can start with:


adb logcat -c

adb logcat

Then:

Uninstall the application from the device.
Start log collection.
Deploy and launch the application again.
Reproduce the crash.

However, adb logcat can produce a very large amount of output, making it difficult to identify the actual issue. You can narrow the results using the following commands.

Show only errors:


adb logcat *:E

Show Android runtime errors and fatal exceptions only:


adb logcat AndroidRuntime:E *:S

Filter for your application process only

Find the PID:


adb shell pidof YOUR_APP_ID

Note: You can find your Application ID in </ApplicationId> .csproj file.

Example output: 12345, then filter logs by PID:


adb logcat --pid=12345

This approach works regardless of whether you're using Visual Studio, VS code, Rider, or the .NET CLI.

I also tested this approach locally by reproducing a similar startup crash scenario in a .NET MAUI application running on Android. The log filtering commands above successfully captured the exception details, which confirms that they are useful for diagnosing startup issues.

Note

Make sure that Android SDK platform-Tools is installed and the folder containing adb.exe has been added to your system PATH environment variable.

You can remove the application either manually from the device or by using:


adb uninstall YOUR_APP_ID

To verify that Logcat can capture startup exceptions correctly, I added the following temporary TEST CODE in App.xaml.cs:


#if DEBUG

if (DeviceInfo.Platform == DevicePlatform.Android)

{

    bool firstRun = Preferences.Default.Get("CrashTest_FirstRun", true);

    if (firstRun)

    {

        Preferences.Default.Set("CrashTest_FirstRun", false);

        throw new Exception("Intentional first-launch crash for testing");

    }

}

#endif

Using:


adb logcat AndroidRuntime:E *:S

the resulting log clearly identified the exception: enter image description here

The stack trace also pointed directly to the location where the exception was thrown, making it much easier to identify the root cause.

The Logcat steps above should make it much easier to identify startup exceptions that may not appear in the debugger output.

If my explanation and the information I provided were helpful, I would greatly appreciate it if you could follow the instruction here so others experiencing similar behavior can benefit from it as well.

mc 7,231 Reputation points

2026-08-04T12:44:17.35+00:00

1.txt

I can not understand it can you look up it for me?
Tony Thach (WICLOUD CORPORATION) 240 Reputation points Microsoft External Staff Moderator

2026-08-05T02:57:24.9166667+00:00
Hello @mc ,

I do not see an unhandled exception or an actual crash. Instead, the app takes too long to initialize on the main UI thread:

Skipped 186 frames! Enter APP_SCOUT_HANG state MainActivity onStart took 5009ms

The stack trace points to MAUI Shell creating the initial UI:

ShellSectionRenderer.onCreateView

Therefore, the first launch takes about 5 seconds and MIUI detects the app as hanging/ANR, which can make it appear as though the app has crashed or quit. Subsequent launches may be faster because assemblies, data, and caches have already been initialized.

Please check startup code in App, AppShell, the initial page/ViewModel, and avoid blocking calls such as .Wait() or .Result(). You can also disable fast deployment and test a release build to confirm whether this is debug-related.

1 additional answer

Your answer

mc 7,231 Reputation points

2026-08-04T12:44:17.35+00:00

1.txt

I can not understand it can you look up it for me?
Tony Thach (WICLOUD CORPORATION) 240 Reputation points Microsoft External Staff Moderator

2026-08-05T02:57:24.9166667+00:00

Hello @mc ,

I do not see an unhandled exception or an actual crash. Instead, the app takes too long to initialize on the main UI thread:

Skipped 186 frames! Enter APP_SCOUT_HANG state MainActivity onStart took 5009ms

The stack trace points to MAUI Shell creating the initial UI:

ShellSectionRenderer.onCreateView

Therefore, the first launch takes about 5 seconds and MIUI detects the app as hanging/ANR, which can make it appear as though the app has crashed or quit. Subsequent launches may be faster because assemblies, data, and caches have already been initialized.

Please check startup code in App, AppShell, the initial page/ViewModel, and avoid blocking calls such as .Wait() or .Result(). You can also disable fast deployment and test a release build to confirm whether this is debug-related.

Answer 1

Use the first-run deployment path as the main clue.

On the first run in an Android emulator, .NET MAUI installs the shared runtime for the targeted API level before deploying the app. That first deployment can behave differently from later runs because the runtime is not yet present. If the emulator is unstable or not fully connected through ADB, the app can quit on that first launch and then work on later launches.

To find the failure point, use this troubleshooting path:

Start the emulator manually
- Open Android Device Manager.
- Start the virtual device directly and wait until it is fully booted.
- Then run the app again from Visual Studio.
Verify ADB can see the emulator
- Open a command prompt.
- Go to the folder containing adb.
- Run:
```
     adb devices
```
- Expected result: the emulator appears in the attached devices list, for example emulator-5554 device.
- If it does not appear, apply Android SDK updates and try launching the emulator again.
Launch the emulator from the command line for more detail
- Start the emulator from the command line instead of Visual Studio so its output is visible.
- This helps expose emulator-side startup problems that may not surface as a managed exception.
Check Device Manager logs
- Review the DeviceManager.log files under: %userprofile%\AppData\Local\Xamarin\Logs\16.0
- These logs are often useful for diagnosing emulator startup and deployment issues.
Recreate the emulator if the app shows “waiting for debugger” or quits only on first launch
- Restart Visual Studio.
- Delete the emulator and create it again.
- This is a documented workaround when the emulator has an internal problem and the debugger cannot attach correctly.
Keep the emulator running between sessions
- After the first successful run, leave the emulator running.
- Later debug sessions are faster because the .NET MAUI shared runtime is already installed.
- If the device is restarted, the runtime is redeployed.
If deploying to a physical device, test there as well
- Plug in the device.
- Select it as the debug target.
- Run the app.
- If the issue only happens on the emulator, that isolates the problem to the emulator environment rather than the app itself.

If there is no exception in the app, the most likely place to find evidence is the emulator/ADB side rather than managed exception output.

References:

the android quit when I first run the APP in .net MAUI?

1. Capture the Android Logcat

2. Common Culprits to Check

The "Child Already Has a Parent" Error

Missing Native Libraries (ABI Mismatch)

Architecture Bug in .NET 9

AOT Compilation and Trimming

1. Capture the Android Logcat

2. Common Culprits to Check

The "Child Already Has a Parent" Error

Missing Native Libraries (ABI Mismatch)

Architecture Bug in .NET 9

AOT Compilation and Trimming

1 additional answer

Your answer