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

[RadoslawKubas]

Description

After upgrade from Xamarin.Forms 4.4.0.991640 to 4.5.282-pre4 I noticed that when

<BundleAssemblies>True</BundleAssemblies>

app crash on start with exception

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.

My working setup for release in 4.4 is

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

in 4.5 everything works fine only if

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

Steps to Reproduce

1. Create new solution
2. Upgrade Xamarin to 4.5.0.282-pre4
3. Set:

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

4. Run app on the real device

Expected Behavior

App starts.

Actual Behavior

App crash with System.IO.FileNotFoundException exception.

Basic Information

• Version with issue: 4.5.0.282-pre4
• Last known good version: 4.4.0.991640
• IDE: Visual Studio 2019
• Platform Target Frameworks:
  • Android: Xamarin.Android 10.1
• Android Support Library Version: 28.0.0.03, AndroidX 1.1.0
• Nuget Packages:
• Affected Devices: all

[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

[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.

[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

[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)

[nhdanh]

I have same problem

[tranb3r]

Similar to https://github.com/xamarin/AndroidX/issues/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

[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

[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): https://github.com/xamarin/Essentials/issues/1198

So add proguard rule:

-keep public class androidx.appcompat.widget.FitWindowsFrameLayout

[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?

[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.

[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 notifications@github.com 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 https://github.com/xamarin/AndroidX/issues/64#issuecomment-609970584, 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

[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.

[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)

https://github.com/xamarin/xamarin-android/issues/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 ?

[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]

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"." https://github.com/xamarin/AndroidX/pull/106

[moljac]

@EDMIStephen

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

https://github.com/xamarin/AndroidX/pull/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:

https://github.com/xamarin/AndroidX/pull/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 https://github.com/xamarin/xamarin-android/pull/4686 @moljac https://github.com/xamarin/AndroidX/pull/106

[moljac]

No.

https://github.com/xamarin/xamarin-android/pull/4686

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

https://github.com/xamarin/AndroidX/pull/106/

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

1. FragmentType for AndroidX
   1. https://github.com/xamarin/AndroidX/issues/88
   2. https://github.com/xamarin/AndroidX/issues/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 - https://github.com/xamarin/xamarin-android/pull/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)