[Xamarin.Android.Build.Tasks] Add support for new InstantRun - #609
Conversation
|
This is failing .apk execution on the emulator: |
202adfc to
d40bc5d
Compare
| char *to_libmonoso = path_combine (to, "libmonosgen-2.0.so"); | ||
| unlink (to_libmonoso); | ||
| char *to_file = path_combine (to, file); | ||
| unlink (to_file); |
There was a problem hiding this comment.
I realize that the original code didn't do this...but we should probably cleanup anyway. ;-)
This should probably be:
int r = unlink (to_file);
if (r < 0 && errno != ENOENT) {
log_warn (LOG_DEFAULT, "Unable to delete file `%s`", to_file);
}Though this raises entire questions about ensuring that memory is freed...
Which means I now get to do what I keep suggesting on ##csharp! "How do we sanely cleanup resources without using goto? By abusing do{}while!"
static void
copy_file_to_internal_location (const char *to_dir, const char *from_dir, const char *file)
{
char *from_file = path_combine (from_dir, file);
char *to_file = NULL;
do {
if (!from_file || !file_exists (from_file))
break;
log_warn (LOG_DEFAULT, "Copying file `%s` from external location `%s` to internal location `%s`",
file, from_dir, to_dir);
to_file = path_combine (to_dir, file);
if (!to_file)
break;
int r = unlink (to_file);
if (r < 0 && errno != ENOENT) {
log_warn (LOG_DEFAULT, "Unable to delete file `%s`: %s", to_file, strerror (errno));
break;
}
if (file_copy (to_file, from_file) < 0) {
log_warn (LOG_DEFAULT, "Copy failed from `%s` to `%s`: %s", from_file, to_file, strerror (errno));
break;
}
set_user_executable (to_file);
} while (0);
free (from_file);
free (to_file);
}There was a problem hiding this comment.
@jonpryor do you still want me to implement this while loop?
| if ((dir = monodroid_opendir (dir_path)) == NULL) | ||
| continue; | ||
|
|
||
| while (readdir_r (dir, &b, &e) == 0 && e) { |
There was a problem hiding this comment.
I suspect that this will break on the Windows build; if we add the full-mono-integration-build Labe and rebuildl, we'll find out. ;-)
Assuming this is the case, we'll need to add a monodroid_readdir() function to util.c and use it here.
|
|
||
| public class MultiDexLoader extends ContentProvider { | ||
|
|
||
| boolean created; |
There was a problem hiding this comment.
I don't see why we need this field. It doesn't appear to be used anywhere, other than onCreate().
|
build |
|
@jonpryor I updated this and added the full build label. not sure if that did anything though? How can you tell? |
Normal PR build will only build one
As such:
|
|
I think this PR should also have a new test, "somewhere/somehow", which sets I'm less certain on how this should look; perhaps we could make e.g. Or perhaps just a new "Hello, World"-esque test would be sufficient to test MultiDex? Either way, this new test should also contain an |
| char *to_libmonoso = path_combine (to, "libmonosgen-2.0.so"); | ||
| unlink (to_libmonoso); | ||
| if (dir_path == NULL || !directory_exists (dir_path)) { | ||
| if (dir_path != NULL) |
There was a problem hiding this comment.
No need to check for null. free(3) will accept the NULL pointer and ignore it:
The free() function.... If ptr is NULL, no operation is performed.
5ac892a to
619b55c
Compare
|
build |
0a8566b to
5fb5ba2
Compare
a2ad397 to
d91761a
Compare
afc9bb6 to
83c325b
Compare
83c325b to
f418e73
Compare
ca83568 to
552bace
Compare
0c88697 to
e8463e5
Compare
e8463e5 to
1442f8b
Compare
|
build |
1442f8b to
fcb2462
Compare
|
build |
833152b to
c0d01a5
Compare
| @@ -0,0 +1,17 @@ | |||
| <?xml version="1.0" encoding="utf-8"?> | |||
There was a problem hiding this comment.
Why do we have this file? It doesn't appear to be used from anywhere, and it's confusing being alongside Main.axml.
| @@ -0,0 +1,49 @@ | |||
| <?xml version="1.0" encoding="utf-8"?> | |||
There was a problem hiding this comment.
Why do we have this file? It doesn't appear to be used from anywhere, and it's confusing being alongside NameFixups.axml.
|
Does this fix https://bugzilla.xamarin.com/show_bug.cgi?id=55050 ? |
|
No. There are still issues for debug (not for release) that need to be
fixed (see my comments earlier). This is a step in the right direction
though.
…On Mon, 17 Sep 2018 at 17:32, Jonathan Pryor ***@***.***> wrote:
Does this fix https://bugzilla.xamarin.com/show_bug.cgi?id=55050 ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#609 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAxeectAzZcHm-VZmjlFdQYNV4pdwWHUks5ub86FgaJpZM4NndPH>
.
|
395d5ee to
4460c76
Compare
| // Older platforms | ||
| Map activities = (HashMap) collection; | ||
| c = activities.values(); | ||
| } else if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT && |
There was a problem hiding this comment.
This will probably fail when building on e.g. API-10, as Build.VERSION_CODES.KITKAT won't exist.
|
build |
1 similar comment
|
build |
This commit does a couple of things. 1) It reworks the monodroid-glue to copy any .so file it finds in the .__override__ directory over to the local app directory. This should allow us to fast deploy native libraries. Which means we no longer need to re-build the apk if a native library changes. 2) Replaces the StubApplication with a new MultiDexLoader ContentProvider. This provider is reposible for doing all the things the previous StubApplication used to do. But because it is not derived from an Application it means we can now support custom Application types for our debug builds.
This commit does a couple of things.
It reworks the monodroid-glue to copy any .so file it finds
in the .override directory over to the local app directory.
This should allow us to fast deploy native libraries. Which means
we no longer need to re-build the apk if a native library changes.
Removes and replaces the
StubApplicationwith a newMultiDexLoaderContentProvider. This provider is responsible for doing some the things
the previous StubApplication used to do. But because it is not
derived from an Application it means we should be able to support
custom Application types for our debug builds. The MultiDexLoader will
run before EVERYTHING else. This is so we can use dex files from the
override directory.
Move the Resource Patching code from StubApplication over to a
dedicated
MonkeyPatcherclass so it is all in one place.Introduce a
ResourceLoaderContentProvider which will deal withpatching the resource in a FastDev environment. This is to support Custom
Application classes.
The problem we had with this is the resource patching requires that the application
be created. But because the code was in the
MultiDexLoaderorStubApplicationthis could not happen since it would require the app to exist. So the solution is to move
the patching to a dedicated ContentProvider which is loaded AFTER the user app has
been created.