profile
viewpoint
Bret Johnson BretJohnson @microsoft Atlanta, GA Xamarin dev, working on UI tooling in Visual Studio

BretJohnson/roslynp 11

Roslyn portable (aka RoslynP) is an experimental Roslyn subset intended for use with any language, not just C# and VB supported by normal Roslyn

BretJohnson/GoalsNet 1

Goal tracker app with support for shared goals

BretJohnson/app-service-api-java-food-trucks 0

Java API App food trucks service sample

startedshirshov/laconic

started time in 4 days

fork BretJohnson/theme-bobthefish

A Powerline-style, Git-aware fish theme optimized for awesome.

fork in 7 days

push eventxamarin/Xamarin.PropertyEditing

Dominique Louis

commit sha 8f6a160f83fcb893dd99e898c1021206cae71af0

Move MakeFirstResponder call to after launching the EditCollection Window. (#721)

view details

Dominique Louis

commit sha d5de1546c3875feed2486c4b0cd0c44b937d705f

Update Provisionator to something more modern (#725)

view details

Dominique Louis

commit sha 03144178603e8758e57b0e61dc9c91f1636520ce

Ensure all the screen elements in this Window have their … (#724) * Ensure all the screen elements in this Window have their AutomationProperties.Name property set, for accessibility. * Fix Resources file, hopefully. * Attempt 2 at fixing Resources file. * Change Null Category test, as we now expect Unnamed instead of null.

view details

Jérémie Laval

commit sha 245ba4422dc4a8ec1e5b3cbf2afd45d74b3c0563

Merge branch 'master' into d16-7-codeflow

view details

Bret Johnson

commit sha 542db868e9b84b709ec718d21498a34fce7a2039

Merge pull request #730 from xamarin/d16-7-codeflow [d16-7] Master codeflow

view details

push time in 20 days

delete branch xamarin/Xamarin.PropertyEditing

delete branch : d16-7-codeflow

delete time in 20 days

issue commentdotnet/maui

Question: XAML Flavor, Architecture & Roadmap

@fisforfaheem Can you (or someone else who would really like to see this) please open a separate issue for that, on Adobe XD / Figma export to XAML. Thanks!

@netonjm and others have been working on a project (https://github.com/netonjm/FigmaSharp), which aims to do just that, for Figma and later Adobe XD. And we'd really like to understand better what the Forms/MAUI community would (or wouldn't) like to see here - and how you'd use it in practice. A MAUI issue seems like a good place to gather community input. If you can create one, and maybe share briefly how you'd see yourself using it, that can help start that conversation. Thanks again.

robloo

comment created time in a month

issue commentdotnet/maui

Work & install without admin right

@GeraudFabien So we can help improve things, can you give some more specifics on what you had to go through here.

First, to clarify (and setting aside the emulator issue for the moment), do you not have Administrator access to your machine at all, so you can't install many programs like say Visual Studio. How did you get past that? By having IT install Visual Studio on your machine? In that case, I can see that having IT do the initial install maybe isn't so bad, but when Visual Studio requires administrator access after the initial install (which it sometimes does today) that could be annoying. We plan to make installing/updating the Android SDKs and virtual device images no longer require admin access - so I think that will help you here, but I wanted to make sure I understand all the issues.

And then on the emulator specifically, do you remember what the "one right that my IT refuse to get me" was? They had some policy in place around not allowing enabling Hyper-V, say? There may be some things we can do to help there too, but knowing more specifics would help. Thanks much for your feedback.

GeraudFabien

comment created time in a month

issue commentMicrosoftDocs/xamarin-docs

Not clear that Xamarin.Forms builds on Xamarin.iOS/Android

Separate from this, but in the same doc, I wonder if we should nix the stuff around Mono, just not calling it out by name now.

We're becoming "one .net" for .net 5/6, and emphasizing how we aren't that today, instead are this different but compatible mono thing, but will be in the future, just seems like extra complexity for the user to understand and not really necessary for a conceptual understanding of Xamarin, especially on an intro page. We don't need to convince users to trust mono. Textually it looks like it would work to remove the Mono references, but keep the text that talks about what the execution environment does.

I can submit a PR if desired for that.

Eilon

comment created time in a month

Pull request review commentxamarin/xamarin-android

[Xamarin.Android.Build.Tasks] add $(_AndroidAllowDeltaInstall) support

     <_MSBuildFiles Include="$(MSBuildSrcDir)\Xamarin.Android.Build.Debugging.Tasks.pdb" />     <_MSBuildFiles Include="$(MSBuildSrcDir)\Xamarin.Android.Common.Debugging.props" />     <_MSBuildFiles Include="$(MSBuildSrcDir)\Xamarin.Android.Common.Debugging.targets" />+    <_MSBuildFiles Include="$(MSBuildSrcDir)\lib\arm64-v8a\installer" />

@jonathanpeppers do we need anything else for this?

jonathanpeppers

comment created time in 2 months

Pull request review commentxamarin/xamarin-android

[Xamarin.Android.Build.Tasks] add $(_AndroidAllowDeltaInstall) support

     <_MSBuildFiles Include="$(MSBuildSrcDir)\Xamarin.Android.Build.Debugging.Tasks.pdb" />     <_MSBuildFiles Include="$(MSBuildSrcDir)\Xamarin.Android.Common.Debugging.props" />     <_MSBuildFiles Include="$(MSBuildSrcDir)\Xamarin.Android.Common.Debugging.targets" />+    <_MSBuildFiles Include="$(MSBuildSrcDir)\lib\arm64-v8a\installer" />

Per @garuma:

they should already have the right entry, the license and copyright is the same as the other tooling (Apache 2.0 copyright Android Open Source Project) but they may need a specific entry for the entries, their system is different

jonathanpeppers

comment created time in 2 months

pull request commentxamarin/xamarin-android

Add resources at end of APK

I switched back to using our workaround & not moving to a new LibZipSharp (not yet), since it seems better to keep those separate. See more context here: https://xamarinhq.slack.com/archives/C03CEGRUW/p1590002325342000

We'll see how the CI tests look now...

BretJohnson

comment created time in 2 months

push eventxamarin/xamarin-android

Bret Johnson

commit sha 5946d0c648a399753d608762dbdcab56b7987f47

Change back to not bump LibZipSharp (yet) and use workaround code instead for now. It seems simpler/better to keep the LibZipSharp change separate, as it also involves moving to a newer version of libzip and (potentially) switching the compiler used on Windows. LibZipSharp can be updated when Markek & Dean feel comfortable, with a separate PR. See more context here https://xamarinhq.slack.com/archives/C03CEGRUW/p1590002325342000

view details

push time in 2 months

pull request commentxamarin/xamarin-android

Add resources at end of APK

As for the crashes (at least on Windows), that should be fixed by the LibZipSharp update to use the right 32 bit libzip.dll. See https://xamarinhq.slack.com/archives/C03CEGRUW/p1589925476196100

As for the timings, let's see where we're at with the fix above. I also wonder if bumping the version of libzip may have affected the timings. cc @grendello We should dig more & maybe time that part separately.

BretJohnson

comment created time in 2 months

Pull request review commentxamarin/xamarin-android

Add resources at end of APK

 void ExecuteWithAbi (string [] supportedAbis, string apkInputPath, string apkOut 						count = 0; 					} 				}++				if (apkInputPathExists) {

Done

BretJohnson

comment created time in 2 months

push eventxamarin/xamarin-android

Bret Johnson

commit sha 63e83c62e534c437765544530adada23107595c2

Move updating from input Apk to separate method

view details

push time in 2 months

push eventxamarin/xamarin-android

Bret Johnson

commit sha 24cc3a0958b8f84c67c9d538e2fb485a8ff36061

Bump to fixed LibZipSharp 0.0.13

view details

push time in 2 months

pull request commentxamarin/xamarin-android

[Xamarin.Android.Build.Tasks] add $(_AndroidAllowDeltaInstall) support

@brendanzagaeski per above, I made this setting internal only for now, renaming it to _AndroidAllowDeltaInstall and removing doc / release notes doc If you're good with all that, can you please approve. Thanks.

jonathanpeppers

comment created time in 2 months

issue openeddeanchalk/XAMLAssetCreator

Generate Icons UI is partially blank

First off, this is pretty cool & thanks for sharing it.

I installed and played with it some and saw the blank-ish UI below for the Generate Icons dialog. Just a heads up on that, if you weren't aware of the issue.

image

created time in 2 months

pull request commentxamarin/xamarin-android

[Xamarin.Android.Build.Tasks] add $(AndroidAllowDeltaInstall) support

I renamed to _AndroidAllowDeltaInstall and removed this from the doc.

See rename changes in this PR and in https://github.com/xamarin/monodroid/pull/1089

jonathanpeppers

comment created time in 2 months

push eventjonathanpeppers/xamarin-android

Bret Johnson

commit sha 19785891f2c573d0c81aba56f72abfbb8ce92a28

Remove option from doc, since we're adding the _ prefix

view details

Bret Johnson

commit sha 9f17d18840e29420cf2cd13570bd74cdbac51921

Rename AndroidAllowDeltaInstall => _AndroidAllowDeltaInstall

view details

push time in 2 months

pull request commentxamarin/xamarin-android

[Xamarin.Android.Build.Tasks] add $(AndroidAllowDeltaInstall) support

On second though, after discussing more with @jonathanpeppers , I'll rename to _AndroidAllowDeltaInstall and we'll leave this undocumented for now.

Later, when/if this is a productized feature, on by default, we can add a different option potentially to disable it.

jonathanpeppers

comment created time in 2 months

pull request commentxamarin/xamarin-android

[Xamarin.Android.Build.Tasks] add $(AndroidAllowDeltaInstall) support

On names, I rather like AndroidUseApkDeltaInstall. @brendanzagaeski @dellis1972 @jonathanpeppers What do you think? Anyone not like that? If no objections, I'll rename the setting to it.

jonathanpeppers

comment created time in 2 months

Pull request review commentxamarin/xamarin-android

[Xamarin.Android.Build.Tasks] add $(AndroidAllowDeltaInstall) support

     <_MSBuildFiles Include="$(MSBuildSrcDir)\Xamarin.Android.Build.Debugging.Tasks.pdb" />     <_MSBuildFiles Include="$(MSBuildSrcDir)\Xamarin.Android.Common.Debugging.props" />     <_MSBuildFiles Include="$(MSBuildSrcDir)\Xamarin.Android.Common.Debugging.targets" />+    <_MSBuildFiles Include="$(MSBuildSrcDir)\arm64-v8a\installer" />+    <_MSBuildFiles Include="$(MSBuildSrcDir)\armeabi-v7a\installer" />+    <_MSBuildFiles Include="$(MSBuildSrcDir)\x86\installer" />

Thanks. And the paths are now updated.

jonathanpeppers

comment created time in 2 months

push eventjonathanpeppers/xamarin-android

Bret Johnson

commit sha 6030801fc4934c17e0ed67b875af613aa2657019

Update installer paths to include lib directory

view details

push time in 2 months

pull request commentxamarin/xamarin-android

[Xamarin.Android.Build.Tasks] add $(AndroidAllowDeltaInstall) support

@brendanzagaeski Maybe we should just remove it from the release notes for now. Would you be OK with that? This is an experimental feature, primarily to enable internal performance testing. We'd rather not make customers aware of it until later, when we have more confidence in how we'll productize it. Ideally, it'll be on by default eventually, but we're not there yet.

jonathanpeppers

comment created time in 2 months

pull request commentxamarin/xamarin-android

[Xamarin.Android.Build.Tasks] add $(AndroidAllowDeltaInstall) support

@brendanzagaeski It's really option 2. Yes, it aims to make deployments faster, but it's conceptually separate from fast deploy and complementary to it. Fast deploy is about taking assemblies out of the APK and installing them quickly (for debug deployments). While DeltaInstall (which is a term Google uses internally in their code though it's not publicized to external devs) makes APK deployments faster - whatever is left in the APK (like resources) can get deployed faster, by only updating parts of the APK that changed.

Android Studio does use this technology. It's used to make "Apply Changes" faster, when only resources are updated, and also make all deploys faster by only installing changes.

Still, this is experimental so we don't want to say much about it, yet. I'm also fine removing it from the release notes, but it's probably a tiny bit better to have it there.

jonathanpeppers

comment created time in 2 months

Pull request review commentxamarin/xamarin-android

[Xamarin.Android.Build.Tasks] add $(AndroidAllowDeltaInstall) support

     <_MSBuildFiles Include="$(MSBuildSrcDir)\Xamarin.Android.Build.Debugging.Tasks.pdb" />     <_MSBuildFiles Include="$(MSBuildSrcDir)\Xamarin.Android.Common.Debugging.props" />     <_MSBuildFiles Include="$(MSBuildSrcDir)\Xamarin.Android.Common.Debugging.targets" />+    <_MSBuildFiles Include="$(MSBuildSrcDir)\arm64-v8a\installer" />+    <_MSBuildFiles Include="$(MSBuildSrcDir)\armeabi-v7a\installer" />+    <_MSBuildFiles Include="$(MSBuildSrcDir)\x86\installer" />

@dellis1972 I moved the installers to the lib directory, with this PR: https://github.com/xamarin/androidtools/pull/231 Can you please review & approve. With that, the installer executable will be in the e.g. lib/x86 subdirectory, next to the other device specific binaries.

jonathanpeppers

comment created time in 2 months

Pull request review commentxamarin/xamarin-android

Add resources at end of APK

 void ExecuteWithAbi (string [] supportedAbis, string apkInputPath, string apkOut 						count = 0; 					} 				}++				HashSet<ulong> deletedEntries = new HashSet<ulong> ();+				if (apkInputPathExists) {+					using (var packaged = new ZipArchiveEx (apkInputPath, FileMode.Open)) {+						foreach (var entry in packaged.Archive) {+							Log.LogDebugMessage ($"Deregistering item {entry.FullName}");+							existingEntries.Remove (entry.FullName);+							if (lastWriteInput <= lastWriteOutput)+								continue;++							long entryIndexInOutput = -1;+							if (apk.Archive.ContainsEntry (entry.FullName, out entryIndexInOutput)) {+								ZipEntry e = apk.Archive.ReadEntry (entry.FullName);+								// check the CRC values as the ModifiedDate is always 01/01/1980 in the aapt generated file.+								if (entry.CRC == e.CRC) {+									Log.LogDebugMessage ($"Skipping {entry.FullName} from {apkInputPath} as its up to date.");+									continue;+								}+							}++							var ms = new MemoryStream ();+							entry.Extract (ms);++							if (entryIndexInOutput != -1) {+								Log.LogDebugMessage ($"Refreshing {entry.FullName} from {apkInputPath}");++								// Force the modified resource to move to the end of the file, by deleting it first so that AddStream adds it+								// back with a new index. Keeping modified resources toward the end optimizes the delta install for the typical+								// dev scenario where the user is editing a few resources but most of the APK contents (e.g. the native libs)+								// don't change and we want to keep their byte offset in the APK fixed. Delta install need not update APK+								// contents that don't change and don't move.+								apk.Archive.DeleteEntry ((ulong) entryIndexInOutput);

I removed this workaround code, with the LibZipSharp update to now skip deleted entries when enumerating. And I bumped xamarin-android to use the new LibZipSharp version 1.0.12, which isn't (yet) published.

@dellis1972 - Can you publish the new LibZipSharp release, from the latest LibZipSharp commit. Again, it should be 1.0.12 (as I bumped the version on the LibZipSharp side). That should be the last thing needed here.

BretJohnson

comment created time in 2 months

push eventxamarin/xamarin-android

Bret Johnson

commit sha 37adaa0469ad82cb947a9d4c8fa46882658c7a73

Make use of the LibZipSharp fix to skip deleted entries For this code to all work properly it requires the latest LibZipSharp, 1.0.12, which is bumped here. With that, our workaround is no longer required to skip deleted entries when enumerating (which would otherwise throw an exception).

view details

Bret Johnson

commit sha 86d468ae751f3c270daaff010421fbdaa3200ce5

Merge branch 'add-resources-at-end-of-apk' of github.com:xamarin/xamarin-android into add-resources-at-end-of-apk

view details

push time in 2 months

push eventxamarin/xamarin-android

Bret Johnson

commit sha 47e25834ed62b5aba5f5b84ea5e3831b66cc7bd1

Make use of the LibZipSharp fix to skip deleted entries For this code to all work properly it requires the latest LibZipSharp, 1.0.12 With that, our workaround is no longer required to skip deleted entries when enumerating (which would otherwise throw an exception).

view details

push time in 2 months

create barnchxamarin/LibZipSharp

branch : bump-version-number

created branch time in 2 months

push eventxamarin/Xamarin.PropertyEditing

Dominique Louis

commit sha d3ec80e8de373f60df70d45f717c0ed1bf875dc6

Fix NRE when SelectionChanged is firing on a null object. (#717) * Fix NRE when SelectionChanged is firing on a disposed object. * Don't forget to hook the SelectionChange up again, after removing everything. * During control re-use, SelectedValue might be null. So check for that.

view details

Bret Johnson

commit sha 04e581026dcf8d789229bb42b729613e732ab480

Merge branch 'master' into d16-7-codeflow

view details

Bret Johnson

commit sha ebb1fa6a76ebffed0fb35b050196271ed0dde69e

Merge pull request #720 from xamarin/d16-7-codeflow [16-7] codeflow from master

view details

push time in 2 months

create barnchxamarin/Xamarin.PropertyEditing

branch : d16-7-codeflow

created branch time in 2 months

delete branch xamarin/Xamarin.PropertyEditing

delete branch : d16-7-codeflow

delete time in 2 months

create barnchxamarin/Xamarin.PropertyEditing

branch : d16-7-codeflow

created branch time in 2 months

create barnchxamarin/LibZipSharp

branch : add-editor-config

created branch time in 2 months

Pull request review commentxamarin/LibZipSharp

Throw exception instead of silently failing if zip save/close fails

 public void Close () 			if (archive == IntPtr.Zero) 				return; -			Native.zip_close (archive);-			foreach (var s in sources) {-				s.Dispose ();+			try {+				if (Native.zip_close (archive) < 0)+					throw GetErrorException ();+			}+			finally {

fixed

BretJohnson

comment created time in 2 months

push eventxamarin/LibZipSharp

Bret Johnson

commit sha 5a61c24317367562e4dc6f6096a6ed493ed1f8f5

Fix finally formatting

view details

push time in 2 months

push eventxamarin/LibZipSharp

Bret Johnson

commit sha 19a3d03d86db4c71a58a83996e67d78896facb90

Undo unintended file attributes change

view details

push time in 2 months

Pull request review commentxamarin/LibZipSharp

Fix enumerating zip with deleted entries

 public ZipEntry ReadEntry (string entryName, bool caseSensitive = false) 			return ReadEntry ((ulong)LookupEntry (entryName, caseSensitive)); 		} -		public ZipEntry ReadEntry (ulong index)+		/// <summary>+		/// Read a zip entry, given an index.+		/// +		/// By default, if the entry is deleted then an exception is thrown (the error will be ErrorCode.Deleted or+		/// ErrorCode.Inval, depending on whether the deleted entry previously existed in the zip or was newly+		/// added - that's just how libzip handles that). If returnNullIfDeleted is true, then null is returned+		/// for deleted entries and an exception is just thrown for other errors.+		/// </summary>+		/// <param name="index">index to read</param>+		/// <param name="returnNullIfDeleted">whether to return null or throw an exception for deleted entries</param>+		/// <returns></returns>+		public ZipEntry ReadEntry (ulong index, bool returnNullIfDeleted = false)

I actually had done that at first, and just changed it back, per your suggestion. So now the parameter is throwIfDeleted (since non delete errors always throw) and I updated the API to maintain backward ABI compatibility.

BretJohnson

comment created time in 2 months

push eventxamarin/LibZipSharp

Bret Johnson

commit sha 65fa52a25f5b6ba72145f11359d569aa0ac7e475

Changed parameter to throwIfDeleted, per PR suggestion

view details

push time in 2 months

pull request commentxamarin/LibZipSharp

Throw exception instead of silently failing if zip save/close fails

Running out of disk space is another example of a save problem that could happen in practice, though it's probably fairly rare, for APKs.

BretJohnson

comment created time in 2 months

PR opened xamarin/LibZipSharp

Reviewers
Throw exception instead of silently failing if zip save/close fails

I saw a case before on my machine where closing the zip would fail to write out changes, but it would fail silently, so it wasn't obvious there was a problem there.

See more details here: https://xamarinhq.slack.com/archives/C03CEGRUW/p1588784048377800

This PR makes those errors explicit, throwing an exception on Close failures, so that the user will see there's a problem, that the ZIP/APK didn't actually get updated.

I'm honestly a little nervous about this change - it seems good conceptually but might there be cases in practice where it's better to fail silently? I'm not sure, but I wanted to create a PR to get feedback from you all on that.

As for my machine, it was a failure to create temp file error (see Slack). The problem went away after I rebooted and I wasn't able to reproduce it again. Probably it was some file in use issue of some kind. This may or may not be a problem customers see in practice (of course, since it fails silently, we have less visibility into whether it is a problem in practice - making the error explicit would help with that at least).

+10 -5

0 comment

1 changed file

pr created time in 2 months

push eventxamarin/LibZipSharp

Bret Johnson

commit sha 59adfebcacd3521a09b77cf18c9ef9f9ee02aeff

Throw exception instead of silently failing if zip save/close fails I saw a case before on my machine where closing the zip would fail to write out changes, but it would fail silently, so it wasn't obvious there was a problem there. See more details here: https://xamarinhq.slack.com/archives/C03CEGRUW/p1588784048377800 This PR makes those errors explicit, throwing an exception on Close failures, so that the user will see there's a problem, that the ZIP/APK didn't actually get updated. I'm honestly a little nervous about this change - it seems good conceptually but might there be cases in practice where it's better to fail silently? I'm not sure, but I wanted to create a PR to get feedback from you all on that. As for my machine, it was a failure to create temp file error (see Slack). The problem went away after I rebooted and I wasn't able to reproduce it again. Probably it was some file in use issue of some kind. This may or may not be a problem customers see in practice (of course, since it fails silently, we have less visibility into whether it is a problem in practice - making the error explicit would help with that at least).

view details

push time in 2 months

create barnchxamarin/LibZipSharp

branch : report-failures-to-save

created branch time in 2 months

Pull request review commentxamarin/xamarin-android

Add resources at end of APK

 void ExecuteWithAbi (string [] supportedAbis, string apkInputPath, string apkOut 						count = 0; 					} 				}++				HashSet<ulong> deletedEntries = new HashSet<ulong> ();+				if (apkInputPathExists) {+					using (var packaged = new ZipArchiveEx (apkInputPath, FileMode.Open)) {+						foreach (var entry in packaged.Archive) {+							Log.LogDebugMessage ($"Deregistering item {entry.FullName}");+							existingEntries.Remove (entry.FullName);+							if (lastWriteInput <= lastWriteOutput)+								continue;++							long entryIndexInOutput = -1;+							if (apk.Archive.ContainsEntry (entry.FullName, out entryIndexInOutput)) {+								ZipEntry e = apk.Archive.ReadEntry (entry.FullName);+								// check the CRC values as the ModifiedDate is always 01/01/1980 in the aapt generated file.+								if (entry.CRC == e.CRC) {+									Log.LogDebugMessage ($"Skipping {entry.FullName} from {apkInputPath} as its up to date.");+									continue;+								}+							}++							var ms = new MemoryStream ();+							entry.Extract (ms);++							if (entryIndexInOutput != -1) {+								Log.LogDebugMessage ($"Refreshing {entry.FullName} from {apkInputPath}");++								// Force the modified resource to move to the end of the file, by deleting it first so that AddStream adds it+								// back with a new index. Keeping modified resources toward the end optimizes the delta install for the typical+								// dev scenario where the user is editing a few resources but most of the APK contents (e.g. the native libs)+								// don't change and we want to keep their byte offset in the APK fixed. Delta install need not update APK+								// contents that don't change and don't move.+								apk.Archive.DeleteEntry ((ulong) entryIndexInOutput);

@grendello @jonpryor - I updated LibZipSharp to handle this. Can you please review that PR, here: https://github.com/xamarin/LibZipSharp/pull/53

After we merge that we'll bump libZipSharp in this PR.

BretJohnson

comment created time in 2 months

push eventxamarin/LibZipSharp

Bret Johnson

commit sha 80b0a8f8e34154a706f80d3aa27cadc02d0baef7

Fix enumerating zip with deleted entries Previously, if a zip had deleted entries then enumerating the entries in the zip would throw an exception - the ReadEntry call on a deleted entry would thrown an exception. With this change, deleted entries are instead skipped in the enumeration.

view details

push time in 2 months

push eventxamarin/LibZipSharp

Bret Johnson

commit sha 82617b56d3543f40360932c1e1e045f6c996e304

Fix enumerating zip with deleted entries Previously, if a zip had deleted entries then enumerating the entries in the zip would throw an exception - the ReadEntry call on a deleted entry would thrown an exception. With this change, deleted entries are instead skipped in the enumeration.

view details

push time in 2 months

push eventxamarin/LibZipSharp

Bret Johnson

commit sha 7f8b3eacd06b3663a0c07f870bbe2dacba3d53bd

Fix enumerating zip with deleted entries Previously, if a zip had deleted entries then enumerating the entries in the zip would throw an exception - the ReadEntry call on a deleted entry would thrown an exception. With this change, deleted entries are instead skipped in the enumeration.

view details

push time in 2 months

push eventxamarin/LibZipSharp

Bret Johnson

commit sha 04812d627276ebab7acc2396d0c35246dd418ca9

Fix enumerating zip with deleted entries Previously, if a zip had deleted entries then enumerating the entries in the zip would throw an exception - the ReadEntry call on a deleted entry would thrown an exception. With this change, deleted entries are instead skipped in the enumeration.

view details

push time in 2 months

push eventxamarin/LibZipSharp

Bret Johnson

commit sha ffe15ced5c5d7e98ff70817b90030ac2506f6442

Fix enumerating zip with deleted entries Previously, if a zip had deleted entries then enumerating the entries in the zip would throw an exception - the ReadEntry call on a deleted entry would thrown an exception. With this change, deleted entries are instead skipped in the enumeration.

view details

push time in 2 months

push eventxamarin/LibZipSharp

Bret Johnson

commit sha d58bcf584affdcf14699878ff9933d69c6cbfc6e

Fix enumerating zip with deleted entries Previously, if a zip had deleted entries then enumerating the entries in the zip would throw an exception - the ReadEntry call on a deleted entry would thrown an exception. With this change, deleted entries are instead skipped in the enumeration.

view details

push time in 2 months

push eventxamarin/LibZipSharp

Bret Johnson

commit sha 79057e45fe4d17c8d115eea7cea933138198c891

Fix enumerating zip with deleted entries Previously, if a zip had deleted entries then enumerating the entries in the zip would throw an exception - the ReadEntry call on a deleted entry would thrown an exception. With this change, deleted entries are instead skipped in the enumeration.

view details

push time in 2 months

push eventxamarin/LibZipSharp

Bret Johnson

commit sha f355134dedd0e03d40287cb91dc39dc8173a86ac

Fix enumerating zip with deleted entries Previously, if a zip had deleted entries then enumerating the entries in the zip would throw an exception - the ReadEntry call on a deleted entry would thrown an exception. With this change, deleted entries are instead skipped in the enumeration.

view details

push time in 2 months

push eventxamarin/LibZipSharp

Bret Johnson

commit sha 5a6ad7129422a65855f587683ecd2a98d1221676

Fix enumerating zip with deleted entries Previously, if a zip had deleted entries then enumerating the entries in the zip would throw an exception - the ReadEntry call on a deleted entry would thrown an exception. With this change, deleted entries are instead skipped in the enumeration.

view details

push time in 2 months

push eventxamarin/LibZipSharp

Bret Johnson

commit sha f5a1491980311051cd8573ae9f1580d09aaeef94

Fix enumerating zip with deleted entries Previously, if a zip had deleted entries then enumerating the entries in the zip would throw an exception - the ReadEntry call on a deleted entry would thrown an exception. With this change, deleted entries are instead skipped in the enumeration.

view details

push time in 2 months

PR opened xamarin/LibZipSharp

Reviewers
Fix enumerating zip with deleted entries

Previously, if a zip had deleted entries then enumerating the entries in the zip would throw an exception - the ReadEntry call on a deleted entry would thrown an exception. With this change, deleted entries are instead skipped in the enumeration.

+112 -10

0 comment

3 changed files

pr created time in 2 months

create barnchxamarin/LibZipSharp

branch : skip-deleted-items-when-enumerating

created branch time in 2 months

push eventjonathanpeppers/xamarin-android

Bret Johnson

commit sha 9df000b33a24f6efda6a858d4fe7ff2b27d761a6

Fix .external

view details

push time in 2 months

push eventjonathanpeppers/xamarin-android

Jonathan Peppers

commit sha 676745274b0cd9c3fa6a65ac36ac919fa8d13fd4

Bump to r8 1.6.82 (#4670) Context: https://r8.googlesource.com/r8/+/refs/tags/1.6.82/ Context: https://mvnrepository.com/artifact/com.android.tools/r8/1.6.82

view details

Jonathan Pobst

commit sha 3f438e46d7b166a3a3ef54c9ffafb5f426760468

[Mono.Android] Use 'merge.SourceFile' to set 'ApiSince' (#4671) Context: https://github.com/xamarin/xamarin-android/pull/4012#issuecomment-573270536 Context: https://github.com/xamarin/xamarin-android/pull/4012#issuecomment-575428822 Context: https://github.com/xamarin/Java.Interop/commit/005e2734d615a28a7d6e2987dade33249e550d3e Context: a348617ab2b9d9152f1ac25059d6f69937709367 Changes: https://github.com/xamarin/java.interop/compare/377c4c7ab50d1f25082c7079214b8075eb25de35...186174c0377a525308e0123160f2b4a96d2ed4aa * xamarin/Java.Interop@186174c: [generator] Use //*/@api-since for RegisterAttribute.ApiSince (#644) * xamarin/Java.Interop@010161d: [generator] slnf file should use relative path. (#641) * xamarin/Java.Interop@942f787: [CI] Add a .NET Core Windows lane. (#640) When `generator --apiversions=FILE` is used, then the `RegisterAttribute.ApiSince` field will be set to contain the API version which introduced a method, e.g. when building `src/Mono.Android`: $ generator.exe --apiversions=$HOME/android-toolchain/sdk/platform-tools/api/api-versions.xml … and `$HOME/android-toolchain/sdk/platform-tools/api/api-versions.xml` contains: <class name="android/view/inspector/IntFlagMapping" since="29"> <extends name="java/lang/Object"/> then `generator` will emit: [Register ("android/view/inspector/IntFlagMapping", DoNotGenerateAcw=true, ApiSince=29)] partial class IntFlagMapping {} Unfortunately, we have found that Google's support of this file isn't guaranteed. Sometimes it is missing, other times it changes in unexpected ways; either can causes `ApiCompat` breakage when building `Mono.Android`, resulting in the removal or modification of the `RegisterAttribute.ApiSince` values. In short, we have lost faith in `api-versions.xml`. xamarin/Java.Interop@186174c updates `generator` so that *instead of* using an `api-versions.xml` file to provide `RegisterAttribute.ApiSince` values, those values can instead come from `//*/@api-since` attributes. The `//*/@api-since` attributes in turn can come from `src/Mono.Android/metadata`, based on the `//*/@merge.SourceFile` attribute values that `build-tools/api-merge` emits (a073d99a). This data is computed directly from the `android.jar` files, and should always be updated and (reasonably) correct. ~~ Notable differences ~~ Our current method provides data for API levels that we do not use for `api-merge`, such as 2, 4, 11, and 14. However we feel it is ok to "lose" this data, as it isn't really useful to our users. That is, if the minimum Xamarin.Android can target is API-21 (a6489813), it is not useful to know that an API was added in API-9, since there is no way to target an API level where the member is not available. As such, we are not collecting data for API levels 21 or below, and all members added in any of those levels are considered to "always" have been available, with no `RegisterAttribute.ApiSince` value. ~~ ApiCompat ~~ This change creates a significant amount of API "breakages" where `RegisterAttribute.ApiSince` is either getting added or removed. Rather than add an additional 25K lines to `acceptable-breakages`, we are updating the reference assembly. [Elsewhere][0] is a list of the `ApiSince` info that changed as a result, for reference. There are no non-`ApiSince` changes. * ~12.3K members previously had no `ApiSince` and now have `ApiSince=22-29`. * ~12.1K members previously had `ApiSince=1-21` and now have no `ApiSince` value. * ~200 related fields changed from `28` to `29`, this seems to be correct from looking at the source files. A snippet of the file: System.String Android.Service.Carrier.CarrierMessagingService.ServiceInterface - 0 => 22 Android.Service.Carrier.CarrierMessagingService..ctor() - 0 => 22 Android.Service.Carrier.CarrierMessagingService.OnBind(Android.Content.Intent) - 0 => 22 Android.Service.Carrier.CarrierMessagingService.OnDownloadMms(Android.Net.Uri, System.Int32, Android.Net.Uri, Android.Service.Carrier.CarrierMessagingService.IResultCallback) - 0 => 22 … Finally, ignore the attribute `T:System.Diagnostics.DebuggerStepThroughAttribute`, which seems to be generated in some versions of Roslyn when using an `async Task` method. My local compiler (VS2019 16.5) generates it but apparently the version on the Mac agents does not. [0]: https://github.com/xamarin/xamarin-android/files/4616691/api-compat-parsed.txt

view details

Mike Bond

commit sha 9de5abda1fb978dd06f4b6ad8a262f71814ee472

[ci] OSS PR Mac build stage (#4626) Add a macOS build stage to the OSS pipeline to serve as a replacement for the [Jenkins OSS PR build][0]. The plan is to use the existing [**Xamarin.Android-OSS**][1] pipeline definition, which will include both the Mac and Linux build stages. Testing has been performed against the [**Xamarin.Android-OSS-PR**][2] pipeline definition, soon to be deprecated. ***Note:*** This change includes support for Release builds only and not for Debug builds. Debug builds could be added as parallel stages. Also includes the following fixes: * Produce the `create-all-packs.binlog` in the expected location. * Avoid `make prepare-update-mono` build breaks when building `xaprepare.csproj` on newly reimaged agents. * Remove the duplicate step to produce plots for Locale tests [0]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android-pr-pipeline-release/ [1]: https://dev.azure.com/xamarin/public/_build?definitionId=48&_a=summary [2]: https://dev.azure.com/xamarin/public/_build?definitionId=52&_a=summary

view details

Jonathan Peppers

commit sha 0ec53c57385aa1da1dc0ab8b79b8148ec23c1e4b

Bump to Guardsquare/proguard/master@ebe9000c [6.2.2] (#4683) Changes: https://github.com/Guardsquare/proguard/compare/proguard5.3.2...proguard6.2.2 This updates our `external/proguard` submodule from: https://github.com/xamarin/proguard To the official ProGuard source on Github: https://github.com/Guardsquare/proguard/ To build only `proguard.jar` and no other optional components, I was able to build `:core` and copy `core.jar` to the proper location. I also added `ignore = dirty` setting, since we lost control of the `.gitignore` setup in the `external/proguard` git submodule. Otherwise we will always show changes to `external/proguard` after a build. Note: xamarin/proguard@6d834737 corresponds roughly to Guardsquare/proguard@b91da636, "missing" only the ignorable commits: * xamarin/proguard@1358e520: Add legal NOTICES * xamarin/proguard@905836d0: Ignore generated directories

view details

Jonathan Pryor

commit sha 268c40d3c82d8d194f64ce63380f5d14dbf3cb4f

Bump to xamarin/monodroid/master@5849ea10 (#4685) Changes: https://github.com/xamarin/monodroid/compare/9242fa4fe5df2413faf12689c522825404b90755...5849ea1078827543cad9c966d27e4ab9915e572d * xamarin/monodroid@5849ea107 [tests] Fix build from xamarin-android (#1093) * xamarin/monodroid@e50ff9a43: Bump to xamarin/androidtools/master@ff35fa96 (#1092) * xamarin/monodroid@3d4f171a0: Bump to xamarin/xamarin-android/master@a01756 (#1087) * xamarin/monodroid@5560daf55: [tools/RuntimeService] base versionCode off xamarin-android (#1088)

view details

Jonathan Peppers

commit sha 799f7310c196ac3d5bb91d2497d9e141ae5eba4f

[Xamarin.Android.Build.Tasks] add $(AndroidAllowDeltaInstall) support Context: https://github.com/xamarin/monodroid/pull/1089 This adds an experimental feature for speeding up incremental deploys. TODO: - [ ] - Update `BuildProcess.md` with docs for the new publish property - [ ] - Add needed files to the installer - [ ] - Add/update one test in `MSBuildDeviceIntegration`, to verify the new feature works - [ ] - After everything is green, we can merge the `monodroid` side and update this PR to target latest xamarin/monodroid/master

view details

Bret Johnson

commit sha 7cb41b187ff00977db253f38127b937a6897a3b2

Add AndroidAllowDeltaInstall description to doc

view details

Bret Johnson

commit sha 1df04f57240915554fde2c05e6efb5e3910ae931

Add new delta install dependencies to installer

view details

Bret Johnson

commit sha c64be488ce3ef2308391fdd189ceb3e4efddd113

Add AndroidAllowDeltaInstall to KnownProperties

view details

Bret Johnson

commit sha 8926a3ea26a3009d191d83be602dd22393dd604a

Add test case for AllowDeltaInstall=true

view details

Bret Johnson

commit sha 1d71ff094e991a37b68317c2894d65e56bbc3d91

Add Xamarin.Android.Deploy.Installer to XA NuGet.config This is needed (currently) for the delta install "installer" exes, which come from here.

view details

Bret Johnson

commit sha 6c1ac44062ac745bb3608c4b7ff823332c529de2

Use "Assemblies" mode for delta install tests

view details

Bret Johnson

commit sha 2cb82fc7385ce2a934bac80ca66bdc2e77bdba87

Updated NuGet feel for installer Jeremie created this new feed, which can house Xamarin public packages. The installer NuGet (normally built manually on Jeremie's machine when updates are needed) live here now.

view details

Bret Johnson

commit sha 5dc8cf735d7ab77ec05e15ee9267324c30d095e1

Update feed name in NuGet.config

view details

Bret Johnson

commit sha 6df4fffc3f7e309b88ba8b1387e8149a4cb641d5

Bumped to latest monodroid deltainstall branch

view details

Bret Johnson

commit sha 83b0a78c39244d6bd5b1a412ac416871a051d344

Fixup test invocation

view details

Bret Johnson

commit sha 271a243034d947c31a634253853dd8763371a5a9

Added release notes for the experimental option

view details

Bret Johnson

commit sha e511243b01d51c6b6ad121a8efcb1bfc79b817e9

Updated release notes text

view details

push time in 2 months

push eventjonathanpeppers/xamarin-android

push time in 2 months

push eventjonathanpeppers/xamarin-android

Bret Johnson

commit sha 00754c05dff144dc227b1094348491473b444dbc

Fix .external, adding monodroid back

view details

push time in 2 months

push eventjonathanpeppers/xamarin-android

Jonathan Peppers

commit sha 676745274b0cd9c3fa6a65ac36ac919fa8d13fd4

Bump to r8 1.6.82 (#4670) Context: https://r8.googlesource.com/r8/+/refs/tags/1.6.82/ Context: https://mvnrepository.com/artifact/com.android.tools/r8/1.6.82

view details

Jonathan Pobst

commit sha 3f438e46d7b166a3a3ef54c9ffafb5f426760468

[Mono.Android] Use 'merge.SourceFile' to set 'ApiSince' (#4671) Context: https://github.com/xamarin/xamarin-android/pull/4012#issuecomment-573270536 Context: https://github.com/xamarin/xamarin-android/pull/4012#issuecomment-575428822 Context: https://github.com/xamarin/Java.Interop/commit/005e2734d615a28a7d6e2987dade33249e550d3e Context: a348617ab2b9d9152f1ac25059d6f69937709367 Changes: https://github.com/xamarin/java.interop/compare/377c4c7ab50d1f25082c7079214b8075eb25de35...186174c0377a525308e0123160f2b4a96d2ed4aa * xamarin/Java.Interop@186174c: [generator] Use //*/@api-since for RegisterAttribute.ApiSince (#644) * xamarin/Java.Interop@010161d: [generator] slnf file should use relative path. (#641) * xamarin/Java.Interop@942f787: [CI] Add a .NET Core Windows lane. (#640) When `generator --apiversions=FILE` is used, then the `RegisterAttribute.ApiSince` field will be set to contain the API version which introduced a method, e.g. when building `src/Mono.Android`: $ generator.exe --apiversions=$HOME/android-toolchain/sdk/platform-tools/api/api-versions.xml … and `$HOME/android-toolchain/sdk/platform-tools/api/api-versions.xml` contains: <class name="android/view/inspector/IntFlagMapping" since="29"> <extends name="java/lang/Object"/> then `generator` will emit: [Register ("android/view/inspector/IntFlagMapping", DoNotGenerateAcw=true, ApiSince=29)] partial class IntFlagMapping {} Unfortunately, we have found that Google's support of this file isn't guaranteed. Sometimes it is missing, other times it changes in unexpected ways; either can causes `ApiCompat` breakage when building `Mono.Android`, resulting in the removal or modification of the `RegisterAttribute.ApiSince` values. In short, we have lost faith in `api-versions.xml`. xamarin/Java.Interop@186174c updates `generator` so that *instead of* using an `api-versions.xml` file to provide `RegisterAttribute.ApiSince` values, those values can instead come from `//*/@api-since` attributes. The `//*/@api-since` attributes in turn can come from `src/Mono.Android/metadata`, based on the `//*/@merge.SourceFile` attribute values that `build-tools/api-merge` emits (a073d99a). This data is computed directly from the `android.jar` files, and should always be updated and (reasonably) correct. ~~ Notable differences ~~ Our current method provides data for API levels that we do not use for `api-merge`, such as 2, 4, 11, and 14. However we feel it is ok to "lose" this data, as it isn't really useful to our users. That is, if the minimum Xamarin.Android can target is API-21 (a6489813), it is not useful to know that an API was added in API-9, since there is no way to target an API level where the member is not available. As such, we are not collecting data for API levels 21 or below, and all members added in any of those levels are considered to "always" have been available, with no `RegisterAttribute.ApiSince` value. ~~ ApiCompat ~~ This change creates a significant amount of API "breakages" where `RegisterAttribute.ApiSince` is either getting added or removed. Rather than add an additional 25K lines to `acceptable-breakages`, we are updating the reference assembly. [Elsewhere][0] is a list of the `ApiSince` info that changed as a result, for reference. There are no non-`ApiSince` changes. * ~12.3K members previously had no `ApiSince` and now have `ApiSince=22-29`. * ~12.1K members previously had `ApiSince=1-21` and now have no `ApiSince` value. * ~200 related fields changed from `28` to `29`, this seems to be correct from looking at the source files. A snippet of the file: System.String Android.Service.Carrier.CarrierMessagingService.ServiceInterface - 0 => 22 Android.Service.Carrier.CarrierMessagingService..ctor() - 0 => 22 Android.Service.Carrier.CarrierMessagingService.OnBind(Android.Content.Intent) - 0 => 22 Android.Service.Carrier.CarrierMessagingService.OnDownloadMms(Android.Net.Uri, System.Int32, Android.Net.Uri, Android.Service.Carrier.CarrierMessagingService.IResultCallback) - 0 => 22 … Finally, ignore the attribute `T:System.Diagnostics.DebuggerStepThroughAttribute`, which seems to be generated in some versions of Roslyn when using an `async Task` method. My local compiler (VS2019 16.5) generates it but apparently the version on the Mac agents does not. [0]: https://github.com/xamarin/xamarin-android/files/4616691/api-compat-parsed.txt

view details

Mike Bond

commit sha 9de5abda1fb978dd06f4b6ad8a262f71814ee472

[ci] OSS PR Mac build stage (#4626) Add a macOS build stage to the OSS pipeline to serve as a replacement for the [Jenkins OSS PR build][0]. The plan is to use the existing [**Xamarin.Android-OSS**][1] pipeline definition, which will include both the Mac and Linux build stages. Testing has been performed against the [**Xamarin.Android-OSS-PR**][2] pipeline definition, soon to be deprecated. ***Note:*** This change includes support for Release builds only and not for Debug builds. Debug builds could be added as parallel stages. Also includes the following fixes: * Produce the `create-all-packs.binlog` in the expected location. * Avoid `make prepare-update-mono` build breaks when building `xaprepare.csproj` on newly reimaged agents. * Remove the duplicate step to produce plots for Locale tests [0]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android-pr-pipeline-release/ [1]: https://dev.azure.com/xamarin/public/_build?definitionId=48&_a=summary [2]: https://dev.azure.com/xamarin/public/_build?definitionId=52&_a=summary

view details

Jonathan Peppers

commit sha 0ec53c57385aa1da1dc0ab8b79b8148ec23c1e4b

Bump to Guardsquare/proguard/master@ebe9000c [6.2.2] (#4683) Changes: https://github.com/Guardsquare/proguard/compare/proguard5.3.2...proguard6.2.2 This updates our `external/proguard` submodule from: https://github.com/xamarin/proguard To the official ProGuard source on Github: https://github.com/Guardsquare/proguard/ To build only `proguard.jar` and no other optional components, I was able to build `:core` and copy `core.jar` to the proper location. I also added `ignore = dirty` setting, since we lost control of the `.gitignore` setup in the `external/proguard` git submodule. Otherwise we will always show changes to `external/proguard` after a build. Note: xamarin/proguard@6d834737 corresponds roughly to Guardsquare/proguard@b91da636, "missing" only the ignorable commits: * xamarin/proguard@1358e520: Add legal NOTICES * xamarin/proguard@905836d0: Ignore generated directories

view details

Jonathan Pryor

commit sha 268c40d3c82d8d194f64ce63380f5d14dbf3cb4f

Bump to xamarin/monodroid/master@5849ea10 (#4685) Changes: https://github.com/xamarin/monodroid/compare/9242fa4fe5df2413faf12689c522825404b90755...5849ea1078827543cad9c966d27e4ab9915e572d * xamarin/monodroid@5849ea107 [tests] Fix build from xamarin-android (#1093) * xamarin/monodroid@e50ff9a43: Bump to xamarin/androidtools/master@ff35fa96 (#1092) * xamarin/monodroid@3d4f171a0: Bump to xamarin/xamarin-android/master@a01756 (#1087) * xamarin/monodroid@5560daf55: [tools/RuntimeService] base versionCode off xamarin-android (#1088)

view details

Jonathan Peppers

commit sha f93ca65472d2913ea6e31ba92f42de7d11a5c904

[Xamarin.Android.Build.Tasks] add $(AndroidAllowDeltaInstall) support Context: https://github.com/xamarin/monodroid/pull/1089 This adds an experimental feature for speeding up incremental deploys. TODO: - [ ] - Update `BuildProcess.md` with docs for the new publish property - [ ] - Add needed files to the installer - [ ] - Add/update one test in `MSBuildDeviceIntegration`, to verify the new feature works - [ ] - After everything is green, we can merge the `monodroid` side and update this PR to target latest xamarin/monodroid/master

view details

Bret Johnson

commit sha d99c7283367d32b43766110f2e3183db78555158

Add AndroidAllowDeltaInstall description to doc

view details

Bret Johnson

commit sha a9201364dc0980dd21f5640a3e457509e91a3265

Add new delta install dependencies to installer

view details

Bret Johnson

commit sha b7197ae87712fdc35143220177d8266d1683f211

Add AndroidAllowDeltaInstall to KnownProperties

view details

Bret Johnson

commit sha 0506820b88a49415f13347ba05262bfbffd0f402

Add test case for AllowDeltaInstall=true

view details

Bret Johnson

commit sha 022becd617cf1e19490f0ef6aa3bf65104ea01a7

Add Xamarin.Android.Deploy.Installer to XA NuGet.config This is needed (currently) for the delta install "installer" exes, which come from here.

view details

Bret Johnson

commit sha a3d512e7cf12d530031e25f4e5ed0495b7a58b46

Use "Assemblies" mode for delta install tests

view details

Bret Johnson

commit sha 32bc3c541e7362129f1d4baab62df623b64fbd97

Updated NuGet feel for installer Jeremie created this new feed, which can house Xamarin public packages. The installer NuGet (normally built manually on Jeremie's machine when updates are needed) live here now.

view details

Bret Johnson

commit sha 7cf18397d52b0f09ca61e193f190169864372b09

Update feed name in NuGet.config

view details

Bret Johnson

commit sha 17751469efa1a591fac4535cf254283b1790656a

Fixup test invocation

view details

Bret Johnson

commit sha 0a957a112c5fca8646ae7d71551f8cb6fc893a88

Added release notes for the experimental option

view details

Bret Johnson

commit sha 28bce4ddfdc6f3754126ec4c35f456d82a5c9289

Updated release notes text

view details

Bret Johnson

commit sha 68a549ea9ff915d511753c95c8643cec84a54e15

Merge branch 'deltainstall' of github.com:jonathanpeppers/xamarin-android into deltainstall

view details

push time in 2 months

Pull request review commentxamarin/xamarin-android

Add resources at end of APK

 void ExecuteWithAbi (string [] supportedAbis, string apkInputPath, string apkOut 						count = 0; 					} 				}++				HashSet<ulong> deletedEntries = new HashSet<ulong> ();+				if (apkInputPathExists) {+					using (var packaged = new ZipArchiveEx (apkInputPath, FileMode.Open)) {+						foreach (var entry in packaged.Archive) {+							Log.LogDebugMessage ($"Deregistering item {entry.FullName}");+							existingEntries.Remove (entry.FullName);+							if (lastWriteInput <= lastWriteOutput)+								continue;++							long entryIndexInOutput = -1;+							if (apk.Archive.ContainsEntry (entry.FullName, out entryIndexInOutput)) {+								ZipEntry e = apk.Archive.ReadEntry (entry.FullName);+								// check the CRC values as the ModifiedDate is always 01/01/1980 in the aapt generated file.+								if (entry.CRC == e.CRC) {+									Log.LogDebugMessage ($"Skipping {entry.FullName} from {apkInputPath} as its up to date.");+									continue;+								}+							}++							var ms = new MemoryStream ();+							entry.Extract (ms);++							if (entryIndexInOutput != -1) {+								Log.LogDebugMessage ($"Refreshing {entry.FullName} from {apkInputPath}");++								// Force the modified resource to move to the end of the file, by deleting it first so that AddStream adds it+								// back with a new index. Keeping modified resources toward the end optimizes the delta install for the typical+								// dev scenario where the user is editing a few resources but most of the APK contents (e.g. the native libs)+								// don't change and we want to keep their byte offset in the APK fixed. Delta install need not update APK+								// contents that don't change and don't move.+								apk.Archive.DeleteEntry ((ulong) entryIndexInOutput);

Answering some of those questions:

Yes the index matches the "index in the zip" and always increases (until the zip is written out). The index is managed by the underlying C libzip code. This is basically the algorithm, from what I observed: When the zip is opened, the index matches the position in the zip file (0 is at the beginning, the max value at the end). While the zip is being modified in memory by libzip, new entries are assigned an index of "previousMaxIndex + 1", so the index always increases and deleted entries keep their current index number (so there's a hole). And then when the zip is written & closed, entries are written in index order with deleted entries skipped, so when the file is reopened the index numbers can be different than before (since deleted entries have their index number reused by whatever non-deleted entry came after - no more holes).

FYI, I was using unzip -Zv <zipfile> to dump the index of the zip and see what order things are in. The index number reported by unzip -Zv is the same as managed by libzip, except that unzip reports indexes as being 1 based while libzip has them as 0 based. But conceptually they are the same, indicating the relative order of entries in the zip.

And yes, Flush can change the index numbers, but fortunately it's not called here.

Anyway, all that said, it would probably be cleaner to update LibZipSharp so that the enumerator can cope with deletions, skipping them instead of throwing an exception. Adding a ReadEntry overload that doesn't throw on deleted items and then calling it from https://github.com/xamarin/LibZipSharp/blob/a0973d4a861bf683cf225bc67111b249999673ce/ZipEntryEnumerator.cs#L59 is probably the best way to do that.

@grendello - would you want to take a look at making that change?

BretJohnson

comment created time in 2 months

Pull request review commentxamarin/xamarin-android

Add resources at end of APK

 void ExecuteWithAbi (string [] supportedAbis, string apkInputPath, string apkOut 						count = 0; 					} 				}++				HashSet<ulong> deletedEntries = new HashSet<ulong> ();

@grendello - do you know if there's a rationale for that? maybe EntryCount can be -1 in some case?

BretJohnson

comment created time in 2 months

push eventjonathanpeppers/xamarin-android

Bret Johnson

commit sha 0cafa42ed15eed5c1ac17eeb8d28df7d3bb15a32

Updated release notes text

view details

push time in 2 months

pull request commentxamarin/xamarin-android

[Xamarin.Android.Build.Tasks] add $(AndroidAllowDeltaInstall) support

@brendanzagaeski - I (finally) added release notes. Can you please approve now.

jonathanpeppers

comment created time in 2 months

push eventjonathanpeppers/xamarin-android

Bret Johnson

commit sha 75bd069bd5b5fb1dffb860e32886fd6787731cd9

Added release notes for the experimental option

view details

push time in 2 months

push eventjonathanpeppers/xamarin-android

Marek Habersack

commit sha 61f09bf2ef0c8f09550e2d77eb97f417432b315b

[packaging] Package interpreter-enabled versions of the Mono runtime (#4638) Context: 42822e0488185cdf4bca7c0bd05b21ad03dfbd7e 42822e04 installed interpreter versions of the Mono runtime into our build tree but did not add code to package them. Adds the necessary entries to include the interpreter runtime in `.pkg` and `.vsix` installer packages.

view details

Jonathan Pryor

commit sha 9cc8d865bbc5c7af9decc1dea6da70696ec07037

Bump to xamarin/Java.Interop/master@377c4c7a (#4631) Changes: https://github.com/xamarin/Java.Interop/compare/ce8dc4001bd7b5ab84c42b9b27711755f051cd2d...377c4c7ab50d1f25082c7079214b8075eb25de35 Fixes: https://github.com/xamarin/java.interop/issues/631 * xamarin/Java.Interop@377c4c7: Bump to xamarin/xamarin-android-tools/master@f5fcb9fd (#637) * xamarin/Java.Interop@857b9a9: [Java.Interop.Export] Begin supporting methods with 14+ params (#635) * xamarin/Java.Interop@9876e31: [Java.Interop.BootstrapTasks] Convert to SDK style project (#609) * xamarin/Java.Interop@cbb50af: [generator-Tests] Use Roslyn for .NET Core Support (#638) * xamarin/Java.Interop@56955d9: [generator] Use custom delegates instead of Func/Action. (#632) * xamarin/Java.Interop@0a77166: [Java.Interop.sln] Commit updated automatically generated guids. (#634)

view details

Jonathan Peppers

commit sha 7dab4ee432dcd1e51c52dfe579023fccaf09c471

[build] install .NET 5 preview 4 nightly build (#4644) Context: https://github.com/xamarin/net5-samples/blob/7607d1cde77f0bef676cb7e1a4290e3150501c56/azure-pipelines.yml Context: https://docs.microsoft.com/azure/devops/pipelines/tasks/tool/dotnet-core-tool-installer Currently, on CI we've been doing: - task: UseDotNet@2 inputs: version: 5.0.100-preview.1.20155.7 This `UseDotNet` Azure DevOps task works for any public release of .NET 5 found here: https://dotnet.microsoft.com/download/dotnet/5.0 However, we need .NET 5 Preview 4, which is not on this public downloads page yet... Luckily, we can use these install scripts *instead*: https://docs.microsoft.com/dotnet/core/tools/dotnet-install-script The main drawback is the powershell script *only* works on Windows, so we have to conditionally use bash on macOS. This allows us to download any build found here: https://github.com/dotnet/installer#installers-and-binaries Now we can get .NET 5 Preview 4 on CI *right now*. This will be important for us to start using changes that may have only landed in dotnet/install/master down the road. On macOS, we also have to set `$PATH` and `$DOTNET_ROOT` for the remainder of the build using: echo "##vso[task.setvariable variable=DOTNET_ROOT]$DOTNET_ROOT" && echo "##vso[task.setvariable variable=PATH]$PATH" When using just `export`, future steps on Azure DevOps did not have the new environment variables set. At some point we can switch back to the `UseDotNet` task when .NET public builds are available.

view details

Jonathan Pryor

commit sha 314e48b29401b3f0a0a061ab93712ce35abd67f2

Bump to xamarin/xamarin-android-tools/master@f5fcb9fd (#4640) Changes: https://github.com/xamarin/xamarin-android-tools/compare/12f52acd4407323b2e1b48ca56bab80ffd97b31e...f5fcb9fd1583ebe928734e8525303a0dbe93c79c * xamarin/xamarin-android-tools@f5fcb9f: [Xamarin.Android.Tools.AndroidSdk] Add support for cmdline-tools (#83) * xamarin/xamarin-android-tools@f473ff9: [AndroidSdkWindows] Guard against exception checking registry (#79) * xamarin/xamarin-android-tools@36d7fee: JetBrains OpenJDK 11 detection (#82)

view details

Marek Habersack

commit sha a017561b1e44c51a9af79fae0baaa50fe01c4123

[typemaps] Handle Java to managed type maps properly (#4656) Fixes: https://github.com/xamarin/xamarin-android/issues/4596 Fixes: https://github.com/xamarin/xamarin-android/issues/4660 Context: https://github.com/xamarin/monodroid/commit/192b1f1b71c98650d04bf0a4e52ee337a054ff4c Context: https://github.com/xamarin/java.interop/blob/fc18c54b2ccf14f444fadac0a1e7e81f837cc470/src/Java.Interop.Tools.JavaCallableWrappers/Java.Interop.Tools.JavaCallableWrappers/TypeNameMapGenerator.cs#L149-L186 Context: https://github.com/xamarin/java.interop/blob/010161d1ef6625b762429334f02e7b15e1f7caae/src/Java.Interop.Tools.JavaCallableWrappers/Java.Interop.Tools.JavaCallableWrappers/TypeNameMapGenerator.cs#L155 ~~ Debug Mode ~~ In some environments, `BundleTest.TestBundleIntegerArrayList2()` fails when using the commercial shared runtime: Test 'Xamarin.Android.RuntimeTests.BundleTest.TestBundleIntegerArrayList2' failed: System.MemberAccessException : Cannot create an instance of Android.Runtime.JavaList`1[T] because Type.ContainsGenericParameters is true. at System.Reflection.RuntimeConstructorInfo.DoInvoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) at System.Reflection.RuntimeConstructorInfo.Invoke (System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) at System.Reflection.ConstructorInfo.Invoke (System.Object[] parameters) at Java.Interop.TypeManager.CreateProxy (System.Type type, System.IntPtr handle, Android.Runtime.JniHandleOwnership transfer) at Java.Interop.TypeManager.CreateInstance (System.IntPtr handle, Android.Runtime.JniHandleOwnership transfer, System.Type targetType) at Java.Lang.Object.GetObject (System.IntPtr handle, Android.Runtime.JniHandleOwnership transfer, System.Type type) at Java.Lang.Object._GetObject[T] (System.IntPtr handle, Android.Runtime.JniHandleOwnership transfer) at Java.Lang.Object.GetObject[T] (System.IntPtr handle, Android.Runtime.JniHandleOwnership transfer) at Android.OS.Bundle.Get (System.String key) at Xamarin.Android.RuntimeTests.BundleTest.TestBundleIntegerArrayList2 () at (wrapper managed-to-native) System.Reflection.RuntimeMethodInfo.InternalInvoke(System.Reflection.RuntimeMethodInfo,object,object[],System.Exception&) at System.Reflection.RuntimeMethodInfo.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) The problem appears to be rooted in ce2bc689. In a pre-ce2bc689 world, there were two separate sets of "typemap" files that the application could use: * Java-to-managed mappings, in `typemap.jm` * Managed-to-Java mappings, in `typemap.mj`. These files did *not* need to have the same number of entries! % unzip /Library/Frameworks/Xamarin.Android.framework/Versions/10.2.0.100/lib/xamarin.android/xbuild/Xamarin/Android/Mono.Android.DebugRuntime-debug.apk typemap.jm % unzip /Library/Frameworks/Xamarin.Android.framework/Versions/10.2.0.100/lib/xamarin.android/xbuild/Xamarin/Android/Mono.Android.DebugRuntime-debug.apk typemap.mj % strings typemap.jm | wc -l 10318 % strings typemap.mj | wc -l 11956 The reason why they have a different number of entries is *aliasing*: there can be *multiple* bindings for a given Java type. The managed-to-Java mappings can contain *all* of them; the Java-to-managed mapping *must* pick Only One. For example, [`java.util.ArrayList`][0] contains (at least?) *three* bindings: * [`Android.Runtime.JavaList`][1] * [`Android.Runtime.JavaList<T>`][2] * `Java.Util.ArrayList` (generated at build time) In a pre-ce2bc689 world, this was "fine": we'd binary search each file *separately* to find type mappings. This changed in ce2bc689, as the typemap information was merged into a *single* array in order to de-duplicate information. This reduced `.apk` size. An unanticipated result of this is that the Java-to-managed mappings can now contain *duplicate* keys, "as if" the original `typemap.jm` had the contents: java/util/ArrayList Android.Runtime.JavaList, Mono.Android java/util/ArrayList Android.Runtime.JavaList`1, Mono.Android java/util/ArrayList Java.Util.ArrayLlist, Mono.Android Whereas pre-ce2bc689 there would have only been the first entry. "Sometimes" this duplication is "fine": the typemap search "Just happens" to return the first entry, or the 3rd entry, and apps continue to work as intended. "Sometimes" it isn't: the typemap binary search finds the 2nd entry, which is a generic type. This results in attempting to instantiate a generic type *without appropriate type parameters*, which results in the aforementioned `MemberAccessException`. Update typemap generation code in `Xamarin.Android.Build.Tasks.dll` so that all the duplicate Java type names will point to the same managed type name. Additionally, make sure we select the managed type in the same fashion the old typemap generator in `Java.Interop` worked: prefer base types to the derived ones if the type is an interface or an abstract class. The effect of this change is that no matter which entry `EmbeddedAssemblies::binary_search()` ends up selecting it will always return the same managed type name for all aliased Java types. ~~ Release config apps ~~ Another issue introduced in ce2bc689 is that we no longer ignore interface and generic types when generating the Java-to-managed maps. This adversely affects the `Release` mode in which it is possible that an attempt to instantiate an open generic type (or an interface) will happen, leading to error similar to: FATAL EXCEPTION: main Process: com.companyname.androidsingleviewapp1, PID: 24068 android.runtime.JavaProxyThrowable: System.MemberAccessException: Cannot create an instance of Com.Contoso.Javalibrary1.Class0`1[T] because Type.ContainsGenericParameters is true. at System.Reflection.RuntimeConstructorInfo.DoInvoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) at System.Reflection.RuntimeConstructorInfo.Invoke (System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) at System.Reflection.ConstructorInfo.Invoke (System.Object[] parameters) at Java.Interop.TypeManager.CreateProxy (System.Type type, System.IntPtr handle, Android.Runtime.JniHandleOwnership transfer) at Java.Interop.TypeManager.CreateInstance (System.IntPtr handle, Android.Runtime.JniHandleOwnership transfer, System.Type targetType) at Java.Lang.Object.GetObject (System.IntPtr handle, Android.Runtime.JniHandleOwnership transfer, System.Type type) at Java.Lang.Object._GetObject[T] (System.IntPtr handle, Android.Runtime.JniHandleOwnership transfer) at Java.Lang.Object.GetObject[T] (System.IntPtr handle, Android.Runtime.JniHandleOwnership transfer) at Com.Contoso.Javalibrary1.Class1.Create () at AndroidSingleViewApp1.MainActivity.OnCreate (Android.OS.Bundle savedInstanceState) at Android.App.Activity.n_OnCreate_Landroid_os_Bundle_ (System.IntPtr jnienv, System.IntPtr native__this, System.IntPtr native_savedInstanceState) at (wrapper dynamic-method) Android.Runtime.DynamicMethodNameCounter.1(intptr,intptr,intptr) at crc647d7dcab8da8ee782.MainActivity.n_onCreate(Native Method) at crc647d7dcab8da8ee782.MainActivity.onCreate(MainActivity.java:29) at android.app.Activity.performCreate(Activity.java:7144) at android.app.Activity.performCreate(Activity.java:7135) at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1271) at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2931) at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3086) at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:78) at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:108) at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:68) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1816) at android.os.Handler.dispatchMessage(Handler.java:106) at android.os.Looper.loop(Looper.java:193) at android.app.ActivityThread.main(ActivityThread.java:6718) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858) Update typemap generation code to also ignore generic types and interfaces when generating the Java to Managed map in `Release` mode. We must not simply skip outputting entries for such types because we need to maintain element count parity between java-to-managed and managed-to-java lookup tables. Therefore, the way we skip such types is to output a type token ID of `0` instead of the actual one. This will cause the runtime code to fail to find a mapping, thus allowing the managed code to deal with such a type properly. ~~ Test Updates ~~ Update `BundleTest.TestBundleIntegerArrayList2()` so that it asserts the runtime *type* of `obj` returned, asserting that it is in fact a `JavaList` and not e.g. `Java.Util.ArrayList` or something. (The linker could otherwise "change" things, and this assertion will ensure that `JavaList` won't be linked away…) Add a unit test for the Release config app bug in Issue #4660; thanks to @brendanzagaeski. It works by provoking the binary search bug by "ensuring" that a *generic* type comes *before* the "normally preferred" *non*-generic type. Thus, even if/when binary search returns the first entry, that would still be the *wrong entry*, because that'll be a generic type! [0]: https://developer.android.com/reference/java/util/ArrayList [1]: https://github.com/xamarin/xamarin-android/blob/61f09bf2ef0c8f09550e2d77eb97f417432b315b/src/Mono.Android/Android.Runtime/JavaList.cs#L11-L13 [2]: https://github.com/xamarin/xamarin-android/blob/61f09bf2ef0c8f09550e2d77eb97f417432b315b/src/Mono.Android/Android.Runtime/JavaList.cs#L667-L668

view details

Marek Habersack

commit sha 93f9d66c5f92bd3ae16943f77f4d58bc64cab7f8

[typemaps] Fix a log statement which may lead to segfault when used (#4673) Fixes: https://github.com/xamarin/xamarin-android/issues/4596 Context: a017561b1e44c51a9af79fae0baaa50fe01c4123 Context: https://gist.github.com/pjcollins/87762e81f1f3c7e8b821356e4612eecf A missing parameter in a call to `log_debug` added iFixes: https://github.com/xamarin/xamarin-android/issues/4596 Context: a017561b1e44c51a9af79fae0baaa50fe01c4123 Context: https://gist.github.com/pjcollins/87762e81f1f3c7e8b821356e4612eecf A missing parameter in a call to `log_debug()` added in a017561b may lead to a segfault when `assembly` log category and `debug` log level are enabled: F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3 in tid 922 (DrawableTinting), pid 922 (DrawableTinting) I crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone I /system/bin/tombstoned: received crash request for pid 922 I crash_dump64: performing dump of process 922 (target tid = 922) F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** F DEBUG : Build fingerprint: 'Android/sdk_phone_x86_64/generic_x86_64:9/PSR1.180720.012/4923214:userdebug/test-keys' F DEBUG : Revision: '0' F DEBUG : ABI: 'x86_64' F DEBUG : pid: 922, tid: 922, name: DrawableTinting >>> com.xamarin.DrawableTinting <<< F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3 F DEBUG : Cause: null pointer dereference F DEBUG : rax 0000000000000000 rbx 00007ffed3c283c0 rcx 0000000000000003 rdx 0000000000000002 F DEBUG : r8 00007ffed3c283c0 r9 00000000ffffffff r10 00007ffed3c283d0 r11 00007ffed3c28824 F DEBUG : r12 00007c88774a2f17 r13 00000000ffffffff r14 0000000000000000 r15 00007ffed3c283d0 F DEBUG : rdi 0000000000000003 rsi 00007ffed3c283bb F DEBUG : rbp 00007ffed3c28f18 rsp 00007ffed3c28288 rip 00007c890f860761 F DEBUG : F DEBUG : backtrace: F DEBUG : #00 pc 0000000000020761 /system/lib64/libc.so (strlen+17) F DEBUG : #01 pc 000000000006e761 /system/lib64/libc.so (__vfprintf+5953) F DEBUG : #02 pc 000000000008df5d /system/lib64/libc.so (vsnprintf+189) F DEBUG : #03 pc 0000000000007b60 /system/lib64/liblog.so (__android_log_vprint+64) F DEBUG : #04 pc 000000000001350c /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (log_debug_nocheck(_LogCategories, char const*, ...)+204) F DEBUG : #05 pc 000000000000de6a /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(char const*)+538) F DEBUG : #06 pc 000000000000df13 /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(_MonoString*)+99) F DEBUG : #07 pc 00000000000d57f8 <anonymous:0000000042d04000> Add the missing parameter to prevent the `SIGSEGV` from happening.n a017561b may lead to a segfault when `assembly` log category and `debug` log level are enabled: F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3 in tid 922 (DrawableTinting), pid 922 (DrawableTinting) I crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone I /system/bin/tombstoned: received crash request for pid 922 I crash_dump64: performing dump of process 922 (target tid = 922) F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** F DEBUG : Build fingerprint: 'Android/sdk_phone_x86_64/generic_x86_64:9/PSR1.180720.012/4923214:userdebug/test-keys' F DEBUG : Revision: '0' F DEBUG : ABI: 'x86_64' F DEBUG : pid: 922, tid: 922, name: DrawableTinting >>> com.xamarin.DrawableTinting <<< F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3 F DEBUG : Cause: null pointer dereference F DEBUG : rax 0000000000000000 rbx 00007ffed3c283c0 rcx 0000000000000003 rdx 0000000000000002 F DEBUG : r8 00007ffed3c283c0 r9 00000000ffffffff r10 00007ffed3c283d0 r11 00007ffed3c28824 F DEBUG : r12 00007c88774a2f17 r13 00000000ffffffff r14 0000000000000000 r15 00007ffed3c283d0 F DEBUG : rdi 0000000000000003 rsi 00007ffed3c283bb F DEBUG : rbp 00007ffed3c28f18 rsp 00007ffed3c28288 rip 00007c890f860761 F DEBUG : F DEBUG : backtrace: F DEBUG : #00 pc 0000000000020761 /system/lib64/libc.so (strlen+17) F DEBUG : #01 pc 000000000006e761 /system/lib64/libc.so (__vfprintf+5953) F DEBUG : #02 pc 000000000008df5d /system/lib64/libc.so (vsnprintf+189) F DEBUG : #03 pc 0000000000007b60 /system/lib64/liblog.so (__android_log_vprint+64) F DEBUG : #04 pc 000000000001350c /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (log_debug_nocheck(_LogCategories, char const*, ...)+204) F DEBUG : #05 pc 000000000000de6a /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(char const*)+538) F DEBUG : #06 pc 000000000000df13 /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(_MonoString*)+99) F DEBUG : #07 pc 00000000000d57f8 <anonymous:0000000042d04000> Add the missing parameter to prevent the `SIGSEGV` from happening.

view details

Jonathan Pobst

commit sha 375e06236bc6947c69da92b0e45bb6f8dca94221

[Mono.Android] Android API-R Developer Preview 4 Binding (#4653) Context: https://web.archive.org/web/20200508133951/https://developer.android.com/preview/overview Android 11 [Developer Preview 4 has been released][0]. * [API diff vs. (unbound) Developer Preview 3][1] * [API diff vs. API-29][2] Google's documented timeline for Android 11 has changed slightly wrt commit 3ca2a07a: * Developer Preview 3 on 2020-Apr-23. We started binding this, but then… * Developer Preview 4 on 2020-May-06, two weeks (!) after DP3. * Beta 1 on 2020-June-03: > We’ll include the final SDK and NDK APIs with this release * Beta 2 in July * Beta 3 in August Timeline wise, the *dates* are "unchanged"; the names have changed. Previously, Beta 2 would be released in June and have final APIs; now, Beta 1 will be released in June and have final APIs. Unfortunately, this initial Developer Preview 4 binding does not contain enumification, unlike the previous DP2 binding. [0]: https://android-developers.googleblog.com/2020/05/android-11-beta-plans.html [1]: https://developer.android.com/sdk/api_diff/r-dp4-incr/changes [2]: https://developer.android.com/sdk/api_diff/r-dp4/changes

view details

Jonathan Peppers

commit sha 51176c6e95f09d52b11cf29a4315c6938fc6ee0b

Bump to google/bundletool/master@0.14.0 (#4668) Changes: https://github.com/google/bundletool/compare/0.10.2...0.14.0 Context: https://github.com/google/bundletool/releases/tag/0.14.0 Context: https://github.com/google/bundletool/issues/149 Context: https://github.com/google/bundletool/issues/128

view details

Jonathan Peppers

commit sha b67b545153f212382657b17a334271d56c1a2f0a

[.NET 5] NuGet workarounds for Xamarin.Forms projects (#4663) Context: https://github.com/xamarin/net5-samples/blob/d525d8a2d60700f52f86372c47e83d646d800aa4/Directory.Android.targets Currently, .NET 5 will not restore *existing* Xamarin.Android NuGet packages. It does not know to map `netcoreapp5.0` to `MonoAndroid10.0`, `MonoAndroid9` etc. We'll need to work around this until this lands: * https://github.com/NuGet/NuGet.Client/pull/3339 To get a Xamarin.Forms project building & running *at all* in `xamarin/net5-samples`, I had to: 1. Change `$(AssetTargetFallback)` 2. Write an MSBuild target to replace any instances of `netstandard2.0\Xamarin.Forms.Platform.dll` with `MonoAndroid10.0\Xamarin.Forms.Platform.dll`. 3. Add additional platform-specific assemblies in `$(PkgXamarin_Forms)\lib\MonoAndroid10.0\` There are still some issues with this: 1. You get a lot of `NU1701` warnings due to `$(AssetTargetFallback)`. 2. Due to: https://github.com/NuGet/docs.microsoft.com-nuget/issues/1955 You have to manually list *every* transitive dependency, which totals around ~36 packages for AndroidX. These drawbacks make it completely impractical to run some subset of our existing MSBuild tests on .NET 5. We would have to list the entire tree of `<PackageReference/>` for every test. Since we might be waiting a bit of time for this, I have been able to come up with some workarounds to solve these problems for now: 1. Add a `Microsoft.Android.Sdk.NuGet.targets` with workarounds that we will completely remove down the road (I hope!). 2. Use `$(PackageTargetFallback)` instead of `$(AssetTargetFallback)`. It does not emit `NU1701` warnings, and transitive dependencies work! It is a deprecated MSBuild property, but should be fine as a workaround. 3. Write a `_FixupNuGetReferences` MSBuild target that runs after `ResolvePackageAssets`. A `<FixupNuGetReferences/>` MSBuild task will remove any `netstandard2.0` assemblies where platform-specific ones exist. It also needs to add platform-specific assemblies that are missing. With this in place, a Xamarin.Forms `.csproj` with no hacks works! <Project Sdk="Microsoft.Android.Sdk"> <PropertyGroup> <TargetFramework>netcoreapp5.0</TargetFramework> <OutputType>Exe</OutputType> </PropertyGroup> <ItemGroup> <PackageReference Include="Xamarin.Forms" Version="4.5.0.617" /> </ItemGroup> </Project> I created a new `XamarinFormsXASdkProject` class for use in our existing .NET 5 MSBuild tests. Other changes: * `$(XamarinAndroidVersion)` needs to be filled out for the AndroidX MSBuild targets: https://github.com/xamarin/XamarinAndroidXMigration/blob/ea130ca0d0e9b3e20edccec02364f36da11ada6b/source/Xamarin.AndroidX.Migration/BuildTasks/Xamarin.AndroidX.Migration.targets#L107 * `$(RuntimeIdentifier)` should have a default value for application projects. * Some tweaks to make `XASdkProject` more flexible. * `Xamarin.ProjectTools.DotNetStandard` projects now support `<Import/>`. * Added AndroidX-compatible `Tabbar.xml` and `Toolbar.xml`

view details

Bret Johnson

commit sha 8d9dd18753902dd01fa0bdeac6a70b0f0e6487d5

Merge branch 'master' into deltainstall

view details

push time in 2 months

Pull request review commentxamarin/xamarin-android

Add resources at end of APK

 public void AndroidResourceChange () 			using (var builder = CreateApkBuilder ()) { 				Assert.IsTrue (builder.Build (proj), "first build should succeed"); -				// AndroidResource change-				proj.LayoutMain += $"{Environment.NewLine}<!--comment-->";+				// Change the AndroidResource body; just adding a comment isn't enough to trigger an APK update+				string orientationTag = "android:orientation=\"vertical\"";+				proj.LayoutMain = proj.LayoutMain.Replace (orientationTag, $"{orientationTag}  android:paddingLeft=\"16dp\""); 				proj.Touch ("Resources\\layout\\Main.axml"); 				Assert.IsTrue (builder.Build (proj), "second build should succeed"); -				var targets = new [] {+				AssertNonResourceTargetsSkipped (builder);+			}+		}++		void AssertNonResourceTargetsSkipped(ProjectBuilder builder)+		{+			var targets = new [] { 					"_ResolveLibraryProjectImports", 					"_GenerateJavaStubs", 					"_CompileJava", 					"_CompileToDalvik", 				};-				foreach (var target in targets) {-					Assert.IsTrue (builder.Output.IsTargetSkipped (target), $"`{target}` should be skipped!");+			foreach (var target in targets) {+				Assert.IsTrue (builder.Output.IsTargetSkipped (target), $"`{target}` should be skipped!");+			}+		}++		[Test]+		public void AndroidChangedResourcesAtEnd ()+		{+			var path = Path.Combine (Root, "temp", TestName);++			var proj = new XamarinAndroidApplicationProject ();+			using (var builder = CreateApkBuilder ()) {+				Assert.IsTrue (builder.Build (proj), "first build should succeed");++				string signedApkPath = Path.Combine (path, proj.OutputPath, "UnnamedProject.UnnamedProject-Signed.apk");++				// Initial resources should at the end of the zip+				using (var zip = ZipArchive.Open (signedApkPath, FileMode.Open)) {+					Assert.AreEqual (37, zip.EntryCount, "Zip entry count");+					AssertZipEntryHasPosition (zip, "res/layout/main.xml", 32);+					AssertZipEntryHasPosition (zip, "resources.arsc", 33);+				}++				AndroidItem.AndroidResource layout2Resource = AddLayout2 (proj);+				Assert.IsTrue (builder.Build (proj), "second build should succeed");+				//TODO: This fails currently as at least _ResolveLibraryProjectImports is run again; bug?+				//AssertNonResourceTargetsSkipped (builder);++				// Added resources should go at the end of the zip+				using (var zip = ZipArchive.Open (signedApkPath, FileMode.Open)) {+					Assert.AreEqual (38, zip.EntryCount, "Zip entry count");+					AssertZipEntryHasPosition (zip, "res/layout/main.xml", 32);+					AssertZipEntryHasPosition (zip, "res/layout/layout2.xml", 33);+					AssertZipEntryHasPosition (zip, "resources.arsc", 34);+				}++				string orientationTag = "android:orientation=\"vertical\"";+				proj.LayoutMain = proj.LayoutMain.Replace (orientationTag, $"{orientationTag}  android:paddingLeft=\"16dp\"");+				proj.Touch ("Resources\\layout\\Main.axml");+				Assert.IsTrue (builder.Build (proj), "third build should succeed");+				AssertNonResourceTargetsSkipped (builder);++				// Updated resources should go at the end of the zip+				using (var zip = ZipArchive.Open (signedApkPath, FileMode.Open)) {++					Assert.AreEqual (38, zip.EntryCount, "Zip entry count");+					AssertZipEntryHasPosition (zip, "res/layout/layout2.xml", 32);+					AssertZipEntryHasPosition (zip, "resources.arsc", 33);+					AssertZipEntryHasPosition (zip, "res/layout/main.xml", 34);+				}++				proj.AndroidResources.Remove (layout2Resource);+				Assert.IsTrue (builder.Build (proj), "fourth build should succeed");+				//TODO: This fails currently as at least _ResolveLibraryProjectImports is run again; bug?+				//AssertNonResourceTargetsSkipped (builder);

removed

BretJohnson

comment created time in 2 months

Pull request review commentxamarin/xamarin-android

Add resources at end of APK

 public void AndroidResourceChange () 			using (var builder = CreateApkBuilder ()) { 				Assert.IsTrue (builder.Build (proj), "first build should succeed"); -				// AndroidResource change-				proj.LayoutMain += $"{Environment.NewLine}<!--comment-->";+				// Change the AndroidResource body; just adding a comment isn't enough to trigger an APK update+				string orientationTag = "android:orientation=\"vertical\"";+				proj.LayoutMain = proj.LayoutMain.Replace (orientationTag, $"{orientationTag}  android:paddingLeft=\"16dp\""); 				proj.Touch ("Resources\\layout\\Main.axml"); 				Assert.IsTrue (builder.Build (proj), "second build should succeed"); -				var targets = new [] {+				AssertNonResourceTargetsSkipped (builder);+			}+		}++		void AssertNonResourceTargetsSkipped(ProjectBuilder builder)+		{+			var targets = new [] { 					"_ResolveLibraryProjectImports", 					"_GenerateJavaStubs", 					"_CompileJava", 					"_CompileToDalvik", 				};-				foreach (var target in targets) {-					Assert.IsTrue (builder.Output.IsTargetSkipped (target), $"`{target}` should be skipped!");+			foreach (var target in targets) {+				Assert.IsTrue (builder.Output.IsTargetSkipped (target), $"`{target}` should be skipped!");+			}+		}++		[Test]+		public void AndroidChangedResourcesAtEnd ()+		{+			var path = Path.Combine (Root, "temp", TestName);++			var proj = new XamarinAndroidApplicationProject ();+			using (var builder = CreateApkBuilder ()) {+				Assert.IsTrue (builder.Build (proj), "first build should succeed");++				string signedApkPath = Path.Combine (path, proj.OutputPath, "UnnamedProject.UnnamedProject-Signed.apk");++				// Initial resources should at the end of the zip+				using (var zip = ZipArchive.Open (signedApkPath, FileMode.Open)) {+					Assert.AreEqual (37, zip.EntryCount, "Zip entry count");+					AssertZipEntryHasPosition (zip, "res/layout/main.xml", 32);+					AssertZipEntryHasPosition (zip, "resources.arsc", 33);+				}++				AndroidItem.AndroidResource layout2Resource = AddLayout2 (proj);+				Assert.IsTrue (builder.Build (proj), "second build should succeed");+				//TODO: This fails currently as at least _ResolveLibraryProjectImports is run again; bug?+				//AssertNonResourceTargetsSkipped (builder);

removed

BretJohnson

comment created time in 2 months

push eventxamarin/xamarin-android

Bret Johnson

commit sha 6ddd5e36e8fb267c8fc4e1b15d22449bb7bd6daa

Removed TODO comments; it's expected

view details

push time in 2 months

pull request commentxamarin/xamarin-android

Add resources at end of APK

@jonathanpeppers and @dellis1972 - I added tests here. Can you both please take a look, especially at the the TODO item in the test (which may or may not be a bug). Otherwise, I believe this PR is good to merge, when you both are comfortable. Thanks.

BretJohnson

comment created time in 2 months

Pull request review commentxamarin/xamarin-android

Add resources at end of APK

 public void AddDirectory (string folder, string folderInArchive, CompressionMeth 		/// <summary> 		/// HACK: aapt2 is creating zip entries on Windows such as `assets\subfolder/asset2.txt` 		/// </summary>-		public void FixupWindowsPathSeparators (Action<string, string> onRename)+		public void FixupWindowsPathSeparators (HashSet<ulong> deletedEntries, Action<string, string> onRename) 		{ 			bool modified = false;-			foreach (var entry in zip) {++			long entryCount = zip.EntryCount;+			if (entryCount < 0)+				return;++			for (ulong i = 0; i < (ulong) entryCount; ++i) {+				// If an entry index has been deleted then ReadEntry will throw a "Entry has been deleted" ZipException.+				// So we skip deleted entries instead+				if (deletedEntries.Contains (i))+					continue;++				var entry = zip.ReadEntry (i);

Unfortunately, not. The foreach enumerator calls ReadEntry for each entry in the zip, which throws an exception if it's deleted. Ultimately, libZipSharp should probably be updated to handle that differently, but I didn't want to change it and enumerating by index is a bit more efficient anyway.

BretJohnson

comment created time in 2 months

Pull request review commentxamarin/xamarin-android

Add resources at end of APK

 void ExecuteWithAbi (string [] supportedAbis, string apkInputPath, string apkOut 						count = 0; 					} 				}++				HashSet<ulong> deletedEntries = new HashSet<ulong> ();+				if (apkInputPathExists) {+					using (var packaged = new ZipArchiveEx (apkInputPath, FileMode.Open)) {+						foreach (var entry in packaged.Archive) {+							Log.LogDebugMessage ($"Deregistering item {entry.FullName}");+							existingEntries.Remove (entry.FullName);+							if (lastWriteInput <= lastWriteOutput)+								continue;++							long entryIndexInOutput = -1;+							if (apk.Archive.ContainsEntry (entry.FullName, out entryIndexInOutput)) {+								ZipEntry e = apk.Archive.ReadEntry (entry.FullName);+								// check the CRC values as the ModifiedDate is always 01/01/1980 in the aapt generated file.+								if (entry.CRC == e.CRC) {+									Log.LogDebugMessage ($"Skipping {entry.FullName} from {apkInputPath} as its up to date.");+									continue;+								}+							}++							var ms = new MemoryStream ();+							entry.Extract (ms);++							if (entryIndexInOutput != -1) {+								Log.LogDebugMessage ($"Refreshing {entry.FullName} from {apkInputPath}");+								+								// Force the modified resource to move to the end of the file, by deleting it first so that AddStream adds it+								// back with a new index. Keeping modified resources toward the end optimizes the delta install for the typical+								// dev scenario where the user is editing a few resources but most of the APK contents (e.g. the native libs)+								// don't change and we want to keep their byte offset in the APK fixed. Delta install need not update APK+								// contents that don't change and don't move.+								apk.Archive.DeleteEntry ((ulong) entryIndexInOutput);+								deletedEntries.Add ((ulong) entryIndexInOutput);+							}+							else Log.LogDebugMessage ($"Adding {entry.FullName} from {apkInputPath}");

fixed

BretJohnson

comment created time in 2 months

push eventxamarin/xamarin-android

Bret Johnson

commit sha bbadcf2754464bb12f8c2808dd905be73431b050

Added resource delete test

view details

push time in 2 months

push eventxamarin/xamarin-android

Bret Johnson

commit sha 968f4eb41c3a92fdc8106a34615eb1f97c6a24db

Add braces, per code style conventions

view details

Bret Johnson

commit sha abd6e73e7289c27cbbf221dde448e719e342081a

Add test to verify updated resources at end of zip

view details

push time in 2 months

push eventjonathanpeppers/xamarin-android

Bret Johnson

commit sha d0e29734c08bccdf28fe526b1ea2186b8f7cdab0

Fixup test invocation

view details

push time in 2 months

push eventjonathanpeppers/xamarin-android

Bret Johnson

commit sha d34739495620a83b69456f61ee859000cd8b53a8

Bumped to latest monodroid deltainstall branch

view details

push time in 2 months

push eventjonathanpeppers/xamarin-android

Bret Johnson

commit sha 424c5c5ff9a6f7e1bd8502621ffe6a2a24905e2c

Update feed name in NuGet.config

view details

push time in 2 months

PR opened xamarin/xamarin-android

Reviewers
Add resources at end of APK

Update the BuildApk logic so that:

  • Resources are added last, not first. That way when an APK is first built, all the resources are at the end, after native libraries, etc.
  • Modified resources are moved from their current position in the zip to the end of the APK. We make libzip do that by deleting the entry before we re-add it, so that it doesn't overwrite it's current index.

For a typical dev inner loop scenario, assemblies are outside the APK (with fast deploy) and the APK contains just native libraries and resources. Of these, the native libraries tend not to change, while resources can change frequently as the customer updates their UI. By keeping frequently changing parts of the APK at the end, we minimize the amount of bytes that need to get updated by delta install. Delta install (and Apply Changes) updates any changed item in the APK and everything after that item (since the offsets of everything after change too when the item changed in size).

Android Studio follows a similar approach, where updated parts of the APK are moved to the end. Though Android Studio does that somewhat differently, using zipflinger, which unlike us allows gaps in the APK, so it minimizes items moving around even more. Perhaps one day we'll use zipflinger too, with that exact same algorithm, but for now we approximate it with the above, while sticking with libzip.

+70 -39

0 comment

2 changed files

pr created time in 2 months

create barnchxamarin/xamarin-android

branch : add-resources-at-end-of-apk

created branch time in 2 months

push eventjonathanpeppers/xamarin-android

Bret Johnson

commit sha 08ad0aebaa3d60ffc884fb7f21e05a7ba4290e0b

Updated NuGet feel for installer Jeremie created this new feed, which can house Xamarin public packages. The installer NuGet (normally built manually on Jeremie's machine when updates are needed) live here now.

view details

push time in 2 months

Pull request review commentxamarin/xamarin-android

[Xamarin.Android.Build.Tasks] add $(AndroidAllowDeltaInstall) support

 public override void OnCreate () 				/* embedAssemblies */    false, 				/* fastDevType */        "Assemblies:Dexes", 			},+			new object[] {+				/* useSharedRuntime */   true,+				/* embedAssemblies */    false,+				/* fastDevType */        "Assemblies:Dexes",+			},+			new object[] {+				/* useSharedRuntime */   true,+				/* embedAssemblies */    false,+				/* fastDevType */        "Assemblies:Dexes",

Updated

jonathanpeppers

comment created time in 2 months

push eventjonathanpeppers/xamarin-android

Bret Johnson

commit sha b673204cf4e9e9ad58f757379075ab5d16960da4

Add Xamarin.Android.Deploy.Installer to XA NuGet.config This is needed (currently) for the delta install "installer" exes, which come from here.

view details

Bret Johnson

commit sha 565fee31621b52999958de6b2cedaf41920dd133

Use "Assemblies" mode for delta install tests

view details

push time in 2 months

push eventjonathanpeppers/xamarin-android

Bret Johnson

commit sha 32c1aac5dd00924a9e5cffa87b884bcc9c00a664

Add AndroidAllowDeltaInstall to KnownProperties

view details

Bret Johnson

commit sha ba786d2a44995e0f413cb370c89b0960648544ab

Add test case for AllowDeltaInstall=true

view details

push time in 2 months

push eventjonathanpeppers/xamarin-android

Bret Johnson

commit sha 874b4c82135870f5cac5f8d1028457d43c6164f7

Add new delta install dependencies to installer

view details

push time in 2 months

push eventjonathanpeppers/xamarin-android

Bret Johnson

commit sha 35a7524bd8bb5829cc89cdb589cd31b415be5f40

Add AndroidAllowDeltaInstall description to doc

view details

push time in 2 months

delete branch xamarin/Xamarin.PropertyEditing

delete branch : d16-7-codeflow

delete time in 3 months

push eventxamarin/Xamarin.PropertyEditing

Michael Cummings

commit sha e41c04bd132e24a16f47f9f358273105afec98c4

Add agent nuget configuration

view details

Michael Cummings

commit sha 42aac4f0c4f6f3e5840ac1e23796bb9de04052ab

Add azure-pipelines.yaml

view details

Michael Cummings (MSFT)

commit sha 69d7abec6bf5643a78f1abe073c8c934b6b7aaad

Update build status link, formatting

view details

Michael Cummings

commit sha 942af609cb8fbc7f00e6cfcbd940b77630dc0afb

Add action to automatically create a PR when the `loc` branch pushed

view details

Michael Cummings (MSFT)

commit sha a0c462272967fdb5e243c7886a79f3c3c581b336

Merge pull request #710 from xamarin/loc_handoff_automation Adding Azure DevOps YAML build file

view details

Alex Corrado

commit sha c93c21240b7f54ad4e03e97c03da8c4395b17e68

Remove the KVO observer from the popover window when it closes Might possibly fix one of the traces in AB#1088162

view details

Michael Cummings (MSFT)

commit sha 8ddbe00c8a53af7d1fa31cbb719a3fcc8471d935

Only run action on loc branch

view details

Bret Johnson

commit sha 6ab4b9ab87b9d1c3282eb2faea979455e5387812

Merge pull request #716 from xamarin/d16-7-codeflow [16-7] codeflow from master

view details

push time in 3 months

push eventxamarin/Xamarin.PropertyEditing

Michael Cummings (MSFT)

commit sha 8ddbe00c8a53af7d1fa31cbb719a3fcc8471d935

Only run action on loc branch

view details

push time in 3 months

create barnchxamarin/Xamarin.PropertyEditing

branch : d16-7-codeflow

created branch time in 3 months

more