Need to support side-loaded typemap files #1917
Assignees
Labels
Area: App+Library Build
Issues when building Library projects or Application projects.
Area: App Runtime
Issues in `libmonodroid.so`.
Area: Commercial
Issues with non-OSS components.
enhancement
Proposed change to current functionality.
Milestone
Comments
jonpryor
added
enhancement
jonpryor
pushed a commit
that referenced
this issue
Sep 25, 2018
Context: https://developer.xamarin.com/releases/android/xamarin.android_7/xamarin.android_7.0/#Fast_Deployment Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=55050 What do we want? To fast deploy *all the things*! Not just assemblies, as is currently supported, but `.dex` files, Android resources, Android assets, shared libraries (`.so` files), the works. If we can avoid updating and re-installing the `.apk`, we want to do so. TODO: Support Fast Deployment of `.jm` and `.mj` files; see #1917 *How* do we do that? Previously, we used `StubApplication.java`, which would "work some magic" to better support loading types from multiple `.dex` files, allow loading Android Resources from multiple locations, etc. The problem with `StubApplication.java` is that it's "too late" in process startup: certain constructs such as `ContentProvider`s are created *before* the `andorid.app.Application` instance is created, meaning those constructs couldn't be handled like the rest of multidex. Avoid that special case by "moving" the `StubApplication.java` logic into the new `MultiDexLoader` types, which are `ContentProvider`s in the spirit of `MonoRuntimeProvider`, and are thus created *before* the `Application` is created. This in turn allows `Application` subclasses to be located *outside* the default `classes.dex` file (multidex!), while still allowing the `Application` type to be resolved and instantiated. Add a new `ResourcePatcher` ContentProvider which "fixes up" various Android types to permit looking up Android Resources from their fast deployment locations. Previously, resource patching required that the Application be created, which prevented custom `Application` types in a multidex environment (it couldn't be found). Moving Resource patching into a separate content provider allows separation of responsibility, and supports custom `Application` subclasses. Finally, rework `monodroid-glue.c` to copy over any `.so` files which are found in the `.__override__` directory into the local app directory, as **dlopen**(3) won't load `.so` files located outside of the local app directory. This enables fast deployment of native libraries.
|
The first part of this is done, the side loading support is in. We now need to look at generating type maps on a per assembly basis. |
|
The second part, typemap generation and runtime support, is implemented in #3992 |
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The
typemap.jmandtypemap.mjfiles are produced as part of the packaging process byTypeNameMapGeneratorand the<GenerateJavaStubs/>task.In order to help improve app performance (Issues #1443, #1829, #1830, #1831) we would like to require the presence and use of the
typemapfiles, removing support for the Reflection-based fallback path, along with obsoletingJava.Interop.TypeManager.RegisterType(string, Type)andJava.Interop.TypeManager.RegisterPackage()andTypeManager.RegisterPackages().However, in order to fully use
typemapfiles, we need to support them in Fast Deployment scenarios. The problem is that thetypemapfiles are currently stored as per-.apkdata. As such, if a library assembly changes in a manner which requires updating the typemap files, theApp.apkmust be rebuilt and redeployed, if only to transfer the updatedtypemapfiles.We need to update
src/monodroidso that it will look for thetypemapfiles in the.__override__directories in addition to the.apkfiles. We can then generatetypemapfiles as per-Assembly data and side-load them along with the corresponding assemblies, ensuring that when a new Assembly is deployed to the device we also deploy updatedtypemapfiles.As a suggestion, we could name the per-assembly files as
typemap-$(AssemblyBaseName).{jm,mj}, e.g.typemap-Mono.Android.jmandtypemap-Mono.Android.mj.The text was updated successfully, but these errors were encountered: