Services with isolated processes and custom Application class fail to resolve overloads properly

[arctouch-felipemomm]

Basically if we have a Custom Application class + a service with IsolatedProcess = true, it crashes.

See more details about it on:

• https://bugzilla.xamarin.com/show_bug.cgi?id=51940

This issue was reported on 2017-01-29, confirmed by Xamarin Team, but no fix so far.

[tipa]

Is there any update on this? The bug is still present

[Digifais]

Bumped into this issue as well and can confirm the bug is still present. Any estimated fix?

[Macjon]

Any updates?

[MediumOne]

The crash is also observed on a Service run in a separate process, which is not an isolated process.

<service android:name=".SeparateProcessService" android:enabled="true" android:process=":sepService" />

This service does not have the android:isolatedProcess="true" attribute set, but this still crashes with the same error.

[Maddy79]

@jonathanpeppers , can you please have a look into this, for us it is a blocker in production release.

[jonathanpeppers]

Jonathan Pryor describes what the problem here is:

Jumping off of Frank in Comment 3, this appears to be related to //service/@android:isolatedProcess.

https://developer.android.com/guide/topics/manifest/service-element.html#isolated

If I remove the use of ServiceAttribute.IsolatedProcess -- thus removing that attribute -- then the ContactSample app works as expected. I also see the log messages I expected to see, which is always a bonus. :-)

I thus have to suspect that //*/@android:isolatedProcess not only has "no permissions of its own," but also doesn't launch any <provider/>s, thus killing our entire bootstrap mechanism.

I have no idea how to fix this right now, or what the timeframe for supporting isolatedProcess will be. Research needed.

Xamarin.Android bootstraps Mono by using an Android content provider:

https://github.com/xamarin/xamarin-android/blob/53cdc642f4c1298b0ff5e3b073113d77f8785124/src/Xamarin.Android.Build.Tasks/Resources/MonoRuntimeProvider.Bundled.java

Content providers are called by Android before the first Application or Activity, and so it is an ideal place to "start up" Mono.

From this content provider written in Java, we can then call into native C/C++ to start Mono, then start managed C# code. This is fundamental to how Xamarin.Android currently works.

It appears that content providers are not called by Android for out of process services. Right now, the problem is we don't know how to fix this. We need a Java callback before the out of process service starts, so if anyone has some ideas, we would like to know, thanks!

[MediumOne]

Just a shot in the dark - The Magisk root managment tool uses ptrace and inotify events to listen for process forks. Can a similar method be used to detect the new process? Magisk runs its process monitor with root privileges to detect all child processes of zygote and unmount some partitions for some processes. But I think root privileges are not required for a process to detect its own child processes. I see one problem with this approach, even though the parent process can detect a child process, I am not sure if we can execute code in the child process to hook a Java callback.

[MediumOne]

Can the bootstrapping be done in Application.onCreate() instead of in ContentProvider.attachinfo()? Or in the Xamarin Application onCreate() code that the Application.onCreate() extends from. Why can't it be done in the Application class lifecycle itself?

I don't understand the bootstrapping mechanism, so I am not sure how big of a change this is.

[VaslD]

I think it’s because Mono bootstrap has to complete before ANY C# code can be run, that includes any Application subclasses defined in C# and thus Application.OnCreate()

But you’re also making a good point that maybe hacking Application (the Java side Application) can be of some help? IIRC multi-dexing uses a somewhat similar mechanism to inject bootstrap code.

I’m also not an expert on Android runtime so just saying.

[jonathanpeppers]

from @MediumOne: The Magisk root managment tool uses ptrace and inotify events to listen for process forks

I think we need a callback inside the new process. I think this would be listening for new processes starting?

from @VaslD: But you’re also making a good point that maybe hacking Application (the Java side Application) can be of some help?

Do we know if the Application class is even called for an out-of-process service?

If so, it might be possible to create a Java Application class that manually starts Mono. You would not be able to have a C# Application class, though.

You could add a Application.java class to a project with a build action of AndroidJavaSource with code exactly like this: https://github.com/xamarin/xamarin-android/blob/53cdc642f4c1298b0ff5e3b073113d77f8785124/src/Xamarin.Android.Build.Tasks/Resources/MonoRuntimeProvider.Bundled.java#L21-L36

I will put this on my list to try and see if I can get it to work.

[007vel]

Any update on that, A Separate process is not running in MAUI. It's a blocking issue.

android:process=":remote"

05-16 16:12:23.777 17622 17622 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0000000000000078
05-16 16:12:23.777 17622 17622 F DEBUG : Cause: null pointer dereference
05-16 16:12:23.777 17622 17622 F DEBUG : x0 0000007a2ebabd28 x1 0000007a2ebabdf0 x2 0000007a2ebabfc8 x3 0000007a2ebabfcc
05-16 16:12:23.777 17622 17622 F DEBUG : x4 0000000000000000 x5 b400007acfacd6a0 x6 0000000000000000 x7 b5f43f81c698dc7e
05-16 16:12:23.777 17622 17622 F DEBUG : x8 0000007a2ebabdf0 x9 0000000000005b1e x10 0000000000000000 x11 0000000000000001
05-16 16:12:23.777 17622 17622 F DEBUG : x12 0000007a3c130c30 x13 00000000000f2b18 x14 00000000000f2ab8 x15 ffffffffffffffff
05-16 16:12:23.777 17622 17622 F DEBUG : x16 0000007a4779bf78 x17 0000007b54996f2c x18 0000007a2e828000 x19 0000007a2ebabdf0
05-16 16:12:23.777 17622 17622 F DEBUG : x20 00000000000000c8 x21 0000000000000000 x22 0000007a2ebb1000 x23 0000007a2ebac010
05-16 16:12:23.777 17622 17622 F DEBUG : x24 0000007b5e26f2f0 x25 0000000000000002 x26 0000007b5e2780b0 x27 0000000000000002
05-16 16:12:23.777 17622 17622 F DEBUG : x28 0000007a2ebabee0 x29 0000007a2ebabd70
05-16 16:12:23.777 17622 17622 F DEBUG : lr 0000007a47696e18 sp 0000007a2ebabd20 pc 0000007a47696e54 pst 0000000020000000