[Bug] [Android] System.IO.FileNotFoundException when <BundleAssemblies>True</BundleAssemblies>

[xamarin]

[Bug] [Android] System.IO.FileNotFoundException when True

[tranb3r]

Here is another repro project:
TestAndroidX.zip

In debug mode, an image will be displayed on the main page.
In release mode, the image is not displayed, because of the exception.

The exception is only happening with <BundleAssemblies>True</BundleAssemblies>.
It makes no difference whether R8 or Linker are enabled or not.
I'm using XF 4.5.0.
This exception can be easily reproduced on the emulator.

Stack trace of the exception (no crash, it's silent):
ImageElementManager: Error loading image: System.IO.FileNotFoundException: Could not load file or assembly 'Xamarin.AndroidX.AppCompat.Resources, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.
File name: 'Xamarin.AndroidX.AppCompat.Resources, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'
at Xamarin.Forms.Platform.Android.FileImageSourceHandler.LoadImageAsync (Xamarin.Forms.ImageSource imagesource, Android.Widget.ImageView imageView, System.Threading.CancellationToken cancellationToken)
at Xamarin.Forms.Platform.Android.ImageViewExtensions.UpdateBitmap (Android.Widget.ImageView imageView, Xamarin.Forms.IImageElement newView, Xamarin.Forms.IImageElement previousView, Xamarin.Forms.ImageSource newImageSource, Xamarin.Forms.ImageSource previousImageSource)
at Xamarin.Forms.Platform.Android.FastRenderers.ImageElementManager.TryUpdateBitmap (Xamarin.Forms.Platform.Android.IImageRendererController rendererController, Android.Widget.ImageView Control, Xamarin.Forms.IImageElement newImage, Xamarin.Forms.IImageElement previous)

[jonpryor]

@15mgm15 asked:

Do we have some sort of work around?

The workaround is to not set $(BundleAssemblies)=True.

After internal discussion, we are strongly considering removing support for $(BundleAssemblies) in .NET 5, as it increases on-device memory use and slows down app startup times.

[melimion]

Guys, do you really need 3 months to fix this? And week to test it?

Many users can't upgrade to XF 4.5 and later because of this issue. And it looks like nobody cares.

[EDMIStephen]

@EDMIStephen

No it is not. Check this RR/branch and activity:

#106

You will notice that it is worked on that bug. Together with 3-4 other bugs and preparations for .NET 5. The comment is mine and it still applies. MkBundle was not meant for obfuscation and size reduction. MkBundle was supposed to be removed in .NET 5. in favor of other tools.

My comment is around the unprofessional message on the PR. It is fine to mention that is shouldn't be used for obfuscation and that the documentation has been changed to further reflect this in another PR. But insinuating users are idiots is not appropriate especially when they are using a feature as documented and you have messages like this in visual studio.

The word obfuscation should also be completely removed from the Bundle assemblies section on this page because it has become clear that it provides no obfuscation. https://docs.microsoft.com/en-us/xamarin/android/deploy-test/release-prep/

[moljac]

@mduchev

Your issue

java.lang.ClassNotFoundException: Didn't find class "androidx.appcompat.widget.FitWindowsFrameLayout" on path: DexPathList[[zip file 

looks like Xamarin.Forms one (it is in Essentials, but it is Forms one):
xamarin/Essentials#1198

So add proguard rule:

-keep public class androidx.appcompat.widget.FitWindowsFrameLayout

[tranb3r]

@brminnick Thank you but this is off topic. We're taking about the size of assemblies folder vs bundle.so file. The difference will be the same whether building an apk or an aab.

[moljac]

@simon10says

is the fixed only thru the link you provided above?

At this moment - yes. There are ready to press the button packages on CI, but it is not public, so I simply pushed those nugets to that repo, so external users could test.

Or will it be pushed thru the main, official channel (XF release)?

XF team is already testing those nugets. OK. There were some improvements/fixes this morning, but they will be able to use them in few minutes.
Then XF will publish XF nugets. When? I don't know. Xamarin.Android ecosystem (AndroidX and Google.Play.Services with Firebase) has different cadence from Xamarin.Android core and Xamarin.Forms.
I did some tests of XF apps this morning, to save time for XF team and it looks good, but they will test for sure.

I cannot promise anything for forms. Android parts will be released as soon as they confirm it.

[simon10says]

@moljac , I might not agree on your attitudes on some of your replies, BUT BUT, as a technical person to another, I still like to thank you for your hard work.

You are the assignee to most of the issues. It seems like you are like a sweatshop child labor in a very very 3rd world country. It's like Xamarin.Auth disappointment all over again. But, Cheer up. I'm not sure what's your position or how high up you are, but it's still better being a technical person and having these discussions than having to deal with the office/project politics. If you can't handle the workload, let your boss know. This is not a hobbyist repository (is this?) where you can ask customer/user to "take it or leave it" (you didn't explicitly, but your frustrated-attitude did). You never know which "big customer" Microsoft is trying to attract, but only to come here and get disheartened replies.

[melimion]

@moljac rebuilt app with new nugets- no issues

[danardelean]

I had/have the same problem and it is only in Release mode.
Tried disabling Xamarin.AndroidX.AppCompat for the linker but I still got the problem.

Another problem with AndroidX (the stable versions) and XF 4.5 pre-release is that you cannot enable r8 (code shrinker) in release.

In the end I rolled back to the old support libraries and everything works.

[tranb3r]

This bug was opened more than one month ago, and it's quite a serious regression.
It's also very easy to reproduce.
Anybody please help. Thank you.
@moljac @jsuarezruiz @mattleibow

[tranb3r]

@moljac
May I remind you that BundleAssemblies option used to be a Visual Studio Enterprise only feature, which means we paid for it !!
So it's not absurd for us to except a hot fix for this kind regression.
Maybe the right thing to do would have been to release a hot fix first, and only after that, engage the discussion about the pros/cons of removing this feature, and the alternatives we would have.

[jsuarezruiz]

@RadoslawKubas Could you attach an example or review the attached one?
Issue9689.zip
I can't reproduce it. I am using Xamarin.Forms 4.5-pre4 and:

<AndroidLinkMode>Full</AndroidLinkMode>
<AotAssemblies>True</AotAssemblies>
<AndroidEnableProfiledAot>false</AndroidEnableProfiledAot>
<EnableLLVM>True</EnableLLVM>
<BundleAssemblies>True</BundleAssemblies>

[VladislavAntonyuk]

I can reproduce it in release mode only

[Redth]

@danardelean can you be more specific about the error you are seeing? Please open a new issue with more details.

[RadoslawKubas]

I checked with latest stable 4.5.0.356 and same problem repeats. I tried to prepare an example, but the problem is that even in my main solution, I can't reproduce it locally. When building same commit with VS2019 Community 16.4.5 it seems to be fine, but with build on Microsoft App Center and publish to Google Play, all prepunch tests fails.

[mduchev]

I am having the exact same issue. On DEBUG everything works fine. If I change the config to Release - the build passes, I can archive the app but as soon as the app starts, the app crashes with the same error.

[mduchev]

Okay, so I managed to produce a sample project and I managed to narrow down the problem, but this time I got a different exception (but at the same time it is kind of similar). It turned out that it isn't due to the BundleAssemblies config. This happens as soon as we choose to use r8 for code shrinking, the app crashes.

Here is the demo project:
DemoAndroidXCrash.zip

Steps to reproduce:

1. Open the solution
2. Build the app in Release config
3. Archive & Distribute it with a whatever signing identity you wish
4. Install the signed apk into a phone
5. Run the app

If we don't have any code shrinking, everything works fine and the app launches successfully. However, if we choose to use code shrinking (and r8 specifically), then the app crashes with the following exception:

Time Device Name Type PID Tag Message
03-02 15:53:09.701 HMD Global Nokia 6.2 Error 26021 AndroidRuntime Caused by: java.lang.ClassNotFoundException: Didn't find class "androidx.appcompat.widget.FitWindowsFrameLayout" on path: DexPathList[[zip file "/data/app/com.companyname.demoandroidxcrash-Pdr5ZJ6GGM0LzJrOyKjpMA==/base.apk"],nativeLibraryDirectories=[/data/app/com.companyname.demoandroidxcrash-Pdr5ZJ6GGM0LzJrOyKjpMA==/lib/arm64, /data/app/com.companyname.demoandroidxcrash-Pdr5ZJ6GGM0LzJrOyKjpMA==/base.apk!/lib/arm64-v8a, /system/lib64]]
at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:134)
at java.lang.ClassLoader.loadClass(ClassLoader.java:379)
at java.lang.ClassLoader.loadClass(ClassLoader.java:312)
at android.view.LayoutInflater.createView(LayoutInflater.java:606)
at android.view.LayoutInflater.createViewFromTag(LayoutInflater.java:790)
at android.view.LayoutInflater.createViewFromTag(LayoutInflater.java:730)
at android.view.LayoutInflater.inflate(LayoutInflater.java:492)
at android.view.LayoutInflater.inflate(LayoutInflater.java:423)
at android.view.LayoutInflater.inflate(LayoutInflater.java:374)
at androidx.appcompat.app.AppCompatDelegateImpl.createSubDecor(Unknown Source:223)
at androidx.appcompat.app.AppCompatDelegateImpl.ensureSubDecor(Unknown Source:4)
at androidx.appcompat.app.AppCompatDelegateImpl.initWindowDecorActionBar(Unknown Source:0)
at androidx.appcompat.app.AppCompatDelegateImpl.getSupportActionBar(Unknown Source:0)
at androidx.appcompat.app.AppCompatDelegateImpl.setSupportActionBar(Unknown Source:7)
at androidx.appcompat.app.AppCompatActivity.setSupportActionBar(Unknown Source:4)
at crc6422feeebb19be5b6f.MainActivity.n_onCreate(Native Method)
at crc6422feeebb19be5b6f.MainActivity.onCreate(Unknown Source:0)
at android.app.Activity.performCreate(Activity.java:7323)
at android.app.Activity.performCreate(Activity.java:7314)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1272)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2930)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3085)
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:6745)
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)
Force finishing activity com.companyname.demoandroidxcrash/crc6422feeebb19be5b6f.MainActivity

[nhdanh]

I have same problem

[tranb3r]

Similar to #45 (which has been closed).
@moljac Could you please take a look ? This is quite serious...

[ognamala]

We have also observed this problem, which happens only in release mode and when Bundle Assemblies is set to true

[nhdanh]

Will fix on new version ?

[Adrien6]

Similar to #45 (which has been closed).
@moljac Could you please take a look ? This is quite serious...

+1

same issue for me.

[Policy56]

Similar to #45 (which has been closed).
@moljac Could you please take a look ? This is quite serious...

I got the same issue, please take a look on it .. Can't update my app

[NicolasNMO]

Similar to #45 (which has been closed).
@moljac Could you please take a look ? This is quite serious...

Same for me, if you can see ? Thank.

[nhdanh]

Same here 4.5.0.495 - still not working for me

[moljac]

@mduchev Please report here if that helps. Thanks

[mattleibow]

Hey folks! After looking at this, I think I have found out what is happening.

Basically, when using the <BundleAssemblies>, the build is making use of mkbundle to embed the dlls into the native file. And, it makes some assumptions: all files named *.resources.dll are satellite resource assemblies and it puts them into a sub folder. And coincidentally, the AndroidX dll happens to be named Xamarin.AndroidX.AppCompat.Resources.dll

This is what is happening now. We will get a solution/workaround ASAP for you folks.

Thanks for your patience and all the info/repros that helped us work this out.

For the folks interested in the code of mkbundle:
https://github.com/mono/mono/blob/9b4736d4c271e9d4e04cafa258ddd58961f1a39f/mcs/tools/mkbundle/mkbundle.cs#L1315-L1317

The logs will have something like this:

[mkbundle] C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\MSBuild\Xamarin\Android\mkbundle.exe --dos2unix=false --nomain --i18n none --bundled-header --mono-api-struct-path "C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\MSBuild\Xamarin\Android\\mkbundle-api.h" --style linux -c -o obj\Release\100\bundles\armeabi-v7a\temp.c -oo obj\Release\100\bundles\armeabi-v7a\assemblies.o -z obj\Release\100\android\shrunk\TestAndroidX.Android.dll obj\Release\100\android\shrunk\FormsViewGroup.dll obj\Release\100\android\shrunk\Java.Interop.dll obj\Release\100\android\shrunk\Mono.Android.dll obj\Release\100\android\shrunk\mscorlib.dll obj\Release\100\android\shrunk\System.Core.dll obj\Release\100\android\shrunk\System.dll obj\Release\100\android\shrunk\System.Numerics.dll obj\Release\100\android\shrunk\System.Xml.dll obj\Release\100\android\shrunk\TestAndroidX.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.Activity.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.Annotation.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.AppCompat.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.AppCompat.Resources.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.Arch.Core.Common.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.Arch.Core.Runtime.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.AsyncLayoutInflater.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.Browser.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.CardView.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.Collection.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.CoordinatorLayout.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.Core.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.CursorAdapter.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.CustomView.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.DocumentFile.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.DrawerLayout.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.Fragment.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.Interpolator.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.Legacy.Support.Core.UI.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.Legacy.Support.Core.Utils.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.Lifecycle.Common.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.Lifecycle.LiveData.Core.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.Lifecycle.LiveData.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.Lifecycle.Runtime.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.Lifecycle.ViewModel.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.Loader.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.LocalBroadcastManager.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.Media.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.Print.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.RecyclerView.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.SavedState.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.SlidingPaneLayout.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.SwipeRefreshLayout.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.Transition.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.VectorDrawable.Animated.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.VectorDrawable.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.VersionedParcelable.dll obj\Release\100\android\shrunk\Xamarin.AndroidX.ViewPager.dll obj\Release\100\android\shrunk\Xamarin.Essentials.dll obj\Release\100\android\shrunk\Xamarin.Forms.Core.dll obj\Release\100\android\shrunk\Xamarin.Forms.Platform.Android.dll obj\Release\100\android\shrunk\Xamarin.Forms.Platform.dll obj\Release\100\android\shrunk\Xamarin.Forms.Xaml.dll obj\Release\100\android\shrunk\Xamarin.Google.Android.Material.dll obj\Release\100\android\shrunk\System.Net.Http.dll obj\Release\100\android\shrunk\System.Drawing.Common.dll obj\Release\100\android\shrunk\System.Runtime.Serialization.dll obj\Release\100\android\shrunk\System.ServiceModel.Internals.dll obj\Release\100\android\shrunk\Mono.Security.dll

[mkbundle stdout] Storing satellite assembly 'C:\Projects\Testing\TestAndroidX\TestAndroidX\TestAndroidX.Android\obj\Release\100\android\shrunk\Xamarin.AndroidX.AppCompat.Resources.dll' with name 'shrunk/Xamarin.AndroidX.AppCompat.Resources.dll'

[nhdanh]

Will fix in release XF or VS ?

[moljac]

@nhdanh
This has nothing to do with XF or VS. It is AndroidX bindings and Xamarin.Android toolchain (very very deep under the hood)

[nhdanh]

I only concern when my project will be fix this error :)

[mattleibow]

@nhdanh most probably it will be fixed (worked around) in an AndroidX or Xamarin.Forms NuGet update. So not needing a wait for a VS update is good.

[15mgm15]

@mattleibow Do we have some sort of work around?

[danardelean]

Hi Jonathan, What I’ve noticed and Why I used bundle assemblies in the past it was because the resulting assembly was smaller (if I am remember right for one application was like 11MB with bundle assemblies and 18Mb without it. I always wondered Why? Thanks, Dan

On Mon, 6 Apr 2020 at 20:45, Jonathan Pryor ***@***.***> wrote: @15mgm15 <https://github.com/15mgm15> asked: Do we have some sort of work around? The workaround is to *not* set $(BundleAssemblies)=True. After internal discussion, we are strongly considering removing support for $(BundleAssemblies) in .NET 5, as it increases on-device memory use and slows down app startup times. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#64 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKKHFY6AT6JWDTX6EH5QVTRLIPNLANCNFSM4K3XHR6Q> .

-- Inviato da Gmail Mobile

[tranb3r]

After internal discussion, we are strongly considering removing support for $(BundleAssemblies) in .NET 5, as it increases on-device memory use and slows down app startup times.

Whaaat ??
For my app, startup time increase is negligible.
However, apk size decrease is quite significant (-40%).

[brminnick]

@tranb3r - I recommend using Android App Bundles to decrease the size of your app that is downloaded from the Google Play Store:

• https://devblogs.microsoft.com/xamarin/android-app-bundle/
• https://channel9.msdn.com/Shows/XamarinShow/Android-App-Bundles-101--The-Xamarin-Show?wa=wsignin1.0

Switching from APK to AAB reduced the downloaded size of my app from 96.5MB to 29.8MB

[mattleibow]

Isn't it making the app bigger? Don't we have to bundle the dlls multiple times per native abi? Maybe there is some dll compression going on then?

[tranb3r]

Isn't it making the app bigger? Don't we have to bundle the dlls multiple times per native abi? Maybe there is some dll compression going on then?

Actually, I'm only building for arm64-v8a, that's why the resulting apk is smaller with assembly bundle (thanks to some kind of dll compression in the bundle.so).
With multiple arch, the apk would indeed be probably bigger with assembly bundles (per abi) than without. But I guess an aab would be smaller, just like the apk with single arch.

[tranb3r]

So, are you going to fix this regression, or not ?

[nhdanh]

any news for fix this bug ?

[moljac]

Related (goodreads.com)

xamarin/xamarin-android#4527

[nhdanh]

any new when XF 4.6 was release. I still get error on XF 4.6

[moljac]

@nhdanh

Thanks for the feedback. The issue is not fixed yet. I work on it.

[EDMIStephen]

@moljac Thanks for working on this. Is there a timeline for when this will be resolved? Cheers.

[svanders]

Hi any updates on this?
Is any help needed, I don;t think I know enough to help fix it, but can certainly help with some testing if there is a branch that we could access to test on our application.

[tranb3r]

@jonpryor @moljac Could you please provide more details about the changes you're proposing ? Any idea when this is going to be fixed ?

[EDMIStephen]

Guys, do you really need 3 months to fix this? And week to test it?

Many users can't upgrade to XF 4.5 and later because of this issue. And it looks like nobody cares.

It might almost be worse than that. See their comment in the PR.

"The users have been warned not to use bundling assemblies for obfuscation and size reduction, but seems that bleach-for-virii movement is worldwide phenomena, so we are creating antidote that will be shipped with CIF and Domestos products. Thus the codename "Bleach antidote"."
#106

[moljac]

@EDMIStephen

No it is not. Check this RR/branch and activity:

#106

You will notice that it is worked on that bug. Together with 3-4 other bugs and preparations for .NET 5. The comment is mine and it still applies. MkBundle was not meant for obfuscation and size reduction. MkBundle was supposed to be removed in .NET 5. in favor of other tools.

[moljac]

@EDMIStephen @melimion @tranb3r

Please, can you open this file

https://github.com/xamarin/AndroidX/blob/master/source/AndroidXProject.cshtml

??

Or this PR:

#106

??

Could you please provide more details about the changes you're proposing ?

1. The best solution would be NOT to use MkBundle for security (obfuscation), because it is
   not secure. It is not too complex to get to mkbundled assemblies. We are aware of the argument
   that it is the only cheap obfuscation tool, but it is not obfuscation tool.

2. Changes: Assembly renamed + TypeForwarding

   Is that OK with you? You can comment on the PR.

Any idea when this is going to be fixed ?

It was fixed, some time ago, but it was waiting for some other fixes (FragmentType, ManifestMerger) and improvements for .NET 5.
Bottom line it is matter of hours to re-publish 1st rounds (I must re publish almost all nugets with this set of fixes and improvements)

[tranb3r]

Are you working on two different fixes for the same issue ? I'd really like some clarification here.
@jonpryor xamarin/xamarin-android#4686
@moljac #106

[moljac]

No.

xamarin/xamarin-android#4686

Is new PR in Android core (nothing to do with AndroidX) and a new feature, based on experience and feedback from users.

#106

Started as fix only for Bundled Assemblies, but in the meantime several other fixes like:

1. FragmentType for AndroidX
   1. #88
   2. #52
2. ManifestMerger
   Based on experience from GpS-FB (Google.Play.Services and Firebase) manifestmerger.jar was added to target files (it is now part of the Android Core build instead of using nuget package)
3. several cleanups for .NET 5

This PR #106 is merely for re-publishing of the nuget packages.

Do you need more clarification?

Thanks

[melimion]

Do you need more clarification?

The question is not what are you doing. The question is why it takes 3 months to make and release fix?

While waiting for another solution for size reduction - xamarin/xamarin-android#4686 - current features should work and be fixed asap

[moljac]

@melimion

The question is why it takes 3 months to make and release fix?

maybe there was something else?

current features should work and be fixed asap

Yes sir. On my way.

BTW you still did not answer my questions?

[tranb3r]

@moljac Thanks for answering. Yes, I do need more clarification.
If the new compression feature is making the bundleassemblies option obsolete, and assuming it's ready (the PR was merged 9 days ago), then why don't you make it available asap for us as a workaround for this issue, instead of spending weeks on a fix ?

[melimion]

BTW you still did not answer my questions?

What exactly questions do you mean?
I see two:

Please, can you open this file
Or this PR:

Sure I can. By this, do you mean just see it or do you need some action there?

Is that OK with you? You can comment on the PR.

It's OK if it works)

[moljac]

@tranb3r

You are welcome.

"Compression feature" is one of the numerous features Android core team is working in order to improve performance (both build and runtime). This will work on all Android apps not only AndroidX, though AndroidX will be used in the future.

This bug was caused by unfortunate coincidence in naming (AppCompat.Resources.dll) and how mkbundle works (moves *.resources.dll into another folder and then AndroidX dll was not found/loaded).

why don't you make it available asap for us as a workaround for this issue, instead of spending weeks on a fix ?

then why don't you make it available asap for us as a workaround for this issue,

because that PR would not solve AndroidX issue.

instead of spending weeks on a fix ?

a fix took couple of days, but there were other issues too with the same or higher priority.

@melimion Said that he can open one file and comment on the PR. This would indicate that this is public open source repo and instead of asking me questions I answer just because I'm trying to be polite and not ignore you, you could build PR nugets,, test them from local feed on your local machine and provide feedback if that works. Otherwise it will take me more time to test and I love to test good. Hate doing fixes twice because I was in a hurry due to someone's pressure. If you need built nugets I have some here:
https://github.com/moljac/Samples.AndroidX/tree/master/nuget-local

[tranb3r]

@moljac
My understanding is that the new "compression feature" does not use mkbundle anymore, right ?
So, why do you think it would not solve this androidx issue, since it's caused by mkbundle moving resources to another folder ?

[moljac]

@tranb3r It would solve app size use case, but not other (and there are some other). mkbundle was supposed to be removed/abandoned, but some of it use cases seemed legitimate, so 1st we did some tests and decided to go and implement those features. The worst fears were that the app size reduction might increase startup time and a lot of effort done in Xamarin.Forms, Xamarin.Android and Xamarin.iOS would be wasted.

"Compression" will need some time to get into stable (because of testing). And as you know a lot of users do not use previews.

[moljac]

It would solve this issue, but so would unticking (not using) mkbundle. Right?

This was part of the work based on feedback and info coming from this issue.

[melimion]

I've tried nugets from https://github.com/moljac/Samples.AndroidX/tree/master/nuget-local with X.F 4.6 and don't see any issues. Images are displayed, no FileNotFoundException.

[moljac]

@melimion THanks a lot! Really appreciated. Waiting for feedback from Xamarin.Forms team

[moljac]

@EDMIStephen
When this bug was discovered we got feedback from several users how they use mkbundle and some where completely wrong for using mkbundle, but reasonable use case to be implemented/added. Some stated that "it is the cheapest obfuscator available" and mkbundle is NOT obfuscator. We cannot guarantee that code cannot be reversed engineered. OK it adds another layer of complexity, but it is not overly complex. If it is used for reducing size it can impact startup times.

We talked about docs too and that was mistake, but written long time ago.

It was fine to mention and warn users not to use mkbundle for what is not intended, but what to say if you keep doing it? Being vocal and demanding something you have been advised not to use/demand and demanding it to be done ASAP is also not professional, Add to that counting man hours spent on issues. Some users are forcing OOS maintainers to simply ignore them, but I don't want to do it for other helpful users. For example did you try nugets containing fixes for this issue? Some users did.

mkbundle was intended for self contained apps, but presenting it as security tool was wrong (not completelty wrong, but mostly). The same as cutting support for it, which in the end was not cut. We all make mistakes.

[moljac]

@tranb3r

May I remind you that BundleAssemblies option used to be a Visual Studio Enterprise only feature, which means we paid for it !!

This was my argument for being against cancelling support of mkbundle or changing the code of it.

Maybe the right thing to do would have been to release a hot fix first, and only after that, engage the discussion about the pros/cons of removing this feature, and the alternatives we would have.

The easiest part of this bug was fixing it on my side, but when this issue appeared I was working on other tasks too. We can go on and on what was right. There are users with the same arguments like yours who think that their problems (or wishes) have higher priority than yours.

Now as we communicate and I call for cooperation - I do test this issue. There are nugets with this hotfix. Did you try them? If I publish them and switch to another tasks I will not come back to this issue for a while, simply because of other tasks and users that are waiting.

[moljac]

Note: typeforwarding for some Xamarin.Forms apps might fail in some cases. Fix added in locally built nugets (link is above).

[tranb3r]

Maybe the right thing to do would have been to release a hot fix first, and only after that, engage the discussion about the pros/cons of removing this feature, and the alternatives we would have.

There are users with the same arguments like yours who think that their problems (or wishes) have higher priority than yours.

I'm not discussing priorities here. I'm challenging your process, which is obviously bad, if it makes you kill a feature instead of fixing a regression.

[moljac]

That is your opinion and you are completely entitled to it. The "sit and wait" process is not much better. Now you can continue with ad-hominem accusations via challenges about process or anything else, while ignoring my arguments (priorities).

Note: feature was not killed and regression is fixed.

And would you be so kind and propose few suggestions for improvements, please?

[simon10says]

@moljac , is the fixed only thru the link you provided above? Or will it be pushed thru the main, official channel (XF release)?

[cleardemon]

Thank you @moljac, I'm sure most of us are very appreciative of yours and others' work 👍

[tranb3r]

The "sit and wait" process is not much better.

May I remind you that I've tried to help you with this issue as much and as quickly as I could, by posting a repro project. This was more than 3 months ago.
Anyway, thank you for the fix.

[moljac]

For those willing to test before publishing:

<PackageReference Include="Xamarin.Forms" Version="4.6.514" />

https://github.com/moljac/Samples.AndroidX/tree/master/nuget-local

[tranb3r]

When using Xamarin.Forms 4.6.514 instead of 4.6.0.800, here is the error I get on building my android app:
7>C:\Users\bertr.nuget\packages\xamarin.androidx.migration\1.0.6\buildTransitive\monoandroid90\Xamarin.AndroidX.Migration.targets(131,9): error : Could not find 1 Android X assemblies, make sure to install the following NuGet packages:
7>C:\Users\bertr.nuget\packages\xamarin.androidx.migration\1.0.6\buildTransitive\monoandroid90\Xamarin.AndroidX.Migration.targets(131,9): error : - Xamarin.AndroidX.AppCompat.Resources
7>C:\Users\bertr.nuget\packages\xamarin.androidx.migration\1.0.6\buildTransitive\monoandroid90\Xamarin.AndroidX.Migration.targets(131,9): error : You can also copy-and-paste the following snippet into your .csproj file:
7>C:\Users\bertr.nuget\packages\xamarin.androidx.migration\1.0.6\buildTransitive\monoandroid90\Xamarin.AndroidX.Migration.targets(131,9): error :

I'm probably doing something wrong...

And by the way, I don't understand why the new version of Xamarin.AndroidX.Migration that is being published is 1.0.0.1, when I'm already using 1.0.6.

[moljac]

@tranb3r

I'm probably doing something wrong...

I don't think so. With more complex samples there might be such issues with transitive dependencies. In some cases I had to manually fix some dependencies by adding explicit dependencies.

Can you post your project file (*.csproj) for Android app only. (PackageReference items), please.

For now:

1. rename Xamarin.AndroidX.AppCompat.Resources to Xamarin.AndroidX.AppCompat.AppCompatResources version is 1.0.0.1

Or let nuget handle transitive dependencies:

Forms will pull everything in:

    <PackageReference Include="Xamarin.Forms" Version="4.6.514" />
    <PackageReference Include="Xamarin.Essentials" Version="1.5.3.2" />

Was your app migrated to AndroidX before? If yes, then you don't need to migrate again. You'll need it if some library references (transitively) Android.Support then types are mapped on CIL level (Mono.Cecil).

I will need more time to explain Migration.

Xamarin.AndroidX.Migration 1.0.0.1 had to be published, because of the mappings in THAT moment. (There were different artifacts bound at that version) and that nuget carries mapping files.

Just simple explanation:

Check 1st config.json published on 20200214 it has 89 artifacts bound. Latest one with 1.0.6 was published on 20200506 it has 96 artifacts. If I would publish updates with version 1.0.6.1 or 1.0.7 there would be mappings for only 89 artifacts, so 7 missing and that would cause problems. When I bump the last published tag on 1.0.6.1 it will contain all artifacts and everything for the mappings. After next release and fixes it will be 1.0.7 or I will publish 1.0.6.1 as 1.0.7.

[tranb3r]

@moljac
Here is my androidapp.csproj packagereferences (I've removed some custom nugets), if it can help.

  <ItemGroup>
    <PackageReference Include="Xamarin.Forms" Version="4.6.514" />
    <PackageReference Include="Xamarin.AndroidX.Work.Runtime" Version="2.3.4.1" />
    <PackageReference Include="Xamarin.AndroidX.Migration" Version="1.0.6" />
    <PackageReference Include="Xamarin.AndroidX.Paging.Common" Version="2.1.2" />
  </ItemGroup>

For the rest of your explanation, sorry but I'm totally lost...

[moljac]

@tranb3r

For the rest of your explanation, sorry but I'm totally lost...

It is OK. I feel that way too. Ping me later if you want deeper info.

I would try several options:

1. removing Xamarin.AndroidX.Migration completely
2. change version of Xamarin.AndroidX.Migration to 1.0.0.1
3. add explicitly Xamarin.AndroidX.AppCompat.AppCompatResources v 1.0.0.1

Please provide feedback.

Today after I publish 1.0.6.1 or 1.0.7 transitive dependency resolving will be easier.

[melimion]

@tranb3r try this:

• clean local nuget caches
• disable all other nuget sources besides local with AndroidX packages
• run "update-package -reinstall"

[moljac]

@melimion
Did updates from friday work for you?

[melimion]

@moljac haven't tried yet, will try today

[moljac]

Nuget setup issue and related sample:

#111

[moljac]

@melimion Thanks a lot for the feedback. Appreciated.

[tranb3r]

@moljac
With new nugets, no more issues in my app.

  <ItemGroup>
    <PackageReference Include="Xamarin.Forms" Version="4.6.514" />
    <PackageReference Include="Xamarin.AndroidX.Work.Runtime" Version="2.3.4.3" />
    <PackageReference Include="Xamarin.AndroidX.Migration" Version="1.0.6.1" />
    <PackageReference Include="Xamarin.AndroidX.Paging.Common" Version="2.1.2.1" />
  </ItemGroup>

Thanks !

[moljac]

@tranb3r NP (you re welcome).
Thank you for the feedback.

[EmilAlipiev]

Sorry, late to the party but actually Xamarin team seems to be right. Bundle into native assemblies reduces size for apk but increases for aab. Here is what i found,
see in this SO post. https://stackoverflow.com/questions/62293367/xamarin-android-app-bundle-with-bundle-into-native-assemblies-increases-size-b

Let me know if you have similar experience.