Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support of AppBundles #2727

Closed
johnthiriet opened this issue Feb 12, 2019 · 58 comments

Comments

@johnthiriet
Copy link

commented Feb 12, 2019

Hello,

As we will soon have to support 64 bits as well as 32 bits applications (https://android-developers.googleblog.com/2019/01/get-your-apps-ready-for-64-bit.html, the support of Android AppBundles will become more and more necessary. I know we can compile an APK per ABIs but it is nothing as convenient as AppBundles.

Also, it seems like the Play Store will support upload 500MB AppBundles (https://android-developers.googleblog.com/2018/10/playtime-2018.html) but this feature will maybe not be opened to traditional APKs.

The support of AppBundles will be a real game changing for us so please share any plan you have.

Thanks,

@tomcurran

This comment has been minimized.

Copy link

commented Feb 19, 2019

We maintain several apps and are concerned about having APK size increase significantly to fulfil the 64 bit requirement. App bundle support would help us a lot with that!

@muhaym

This comment has been minimized.

Copy link

commented Feb 26, 2019

This will help to maintain the size after AOT builds and multiple abi inside single appbundle.

Flutter just included it in 1.2 launch https://developers.googleblog.com/2019/02/launching-flutter-12-at-mobile-world.html

@dellis1972

This comment has been minimized.

Copy link
Contributor

commented Feb 27, 2019

After doing an initial read though of the documents on App Bundle it seems we will need a bit of work to implement this particular feature. Users should be following googles recommendations on organising resources to prepare for this set of features.

We cannot use the aapt2 which is shipped with the sdk. The docs say the sdk version does not support the required --proto-format argument.

We need to ship the bundletool from github which is the tool that is needed to generate the aab files which are then used to generate the apk.

We also need to do the bindings for Google Play Core . This provides the support for delivering dynamic features.

We need to figure out how to support building the aab files. Should it be opt-in or automatic. There are other publishing stores which probably don't use this tooling to we need to make sure we can still produce an apk. We also need to figure out how best to expose this to the end user. Should it be a new set of project types. It should support being able to break up the app into features somehow.

The features stuff will probably cause all sorts or issues itself. Looking at the sample we might need to figure out how to support this in the mono runtime itself. Normally assemblies are loaded by the runtime at startup. With this new feature we will need to be able to dynamically load new assemblies as they are installed by the feature system.

@dellis1972

This comment has been minimized.

Copy link
Contributor

commented Feb 27, 2019

A note for our future selves com.google.android.play.core.splitinstall.SplitInstallStateUpdatedListener does have status’s which would inform of when a new feature is installed https://github.com/googlesamples/android-dynamic-features/blob/master/app/src/main/java/com/google/android/samples/dynamicfeatures/MainActivity.kt#L54

@johnthiriet

This comment has been minimized.

Copy link
Author

commented Mar 10, 2019

In my opinion the aab building should be opt-in since as you correctly said, some stores won't probably use this tooling.
I know this whole thing will require lot of work, let me know if I can help on some things though if it involves the mono runtime I will probably not be of a great help.

jonathanpeppers added a commit to jonathanpeppers/xamarin-android that referenced this issue Mar 18, 2019
Context: xamarin#2727

This is a prototype that gets us this far:

* We generate a `.aab` file
* We can generate a `.apks` file specific for an attached device
* We can *install* the `.apks` file
* The app starts successfully!

This workflow is achieved by:

* The `<Aapt2Link/>` MSBuild task needs to pass `--proto-format`.
* The `<AppBundleBaseZip/>` and `<BundleToolBuildBundle/>` MSBuild
  tasks run instead of `<BuildApk/>`.
* The `<BundleToolBuildApkSet/>` and `<BundleToolInstallApkSet/>`
  tasks run instead of `adb install`. These are somewhat odd, but they
  use the attached device to decide which format APK set is needed.
  Otherwise the APK set was 200MB!

Some notes about Android App Bundles:

* App bundles use `android:extractNativeLibs="false"`, unless the
  target device's API level is too low.
* `$(AndroidUseAapt2)` is required.
* `$(EmbedAssembliesIntoApk)` is required.
* `$(_EmbeddedDSOsEnabled)` is required, regardless of
  `android:extractNativeLibs` value in `AndroidManifest.xml`.
* `$(AndroidUseApkSigner)` is turned off.
* `$(AndroidUseSharedRuntime)` is turned off.

~~ Java.Interop ~~

Some changes are needed in `MonoRuntimeProvider.Bundled.java` in
java.interop before we can merge this.

We need the "split apks" to be in the list of APKs by calling
`ApplicationInfo.splitPublicSourceDirs`:

https://developer.android.com/reference/android/content/pm/ApplicationInfo.html#splitPublicSourceDirs
jonathanpeppers added a commit to jonathanpeppers/xamarin-android that referenced this issue Mar 22, 2019
Context: xamarin#2727

This is a prototype that gets us this far:

* We generate a `.aab` file
* We can generate a `.apks` file specific for an attached device
* We can *install* the `.apks` file
* The app starts successfully!

This workflow is achieved by:

* The `<Aapt2Link/>` MSBuild task needs to pass `--proto-format`.
* The `<AppBundleBaseZip/>` and `<BundleToolBuildBundle/>` MSBuild
  tasks run instead of `<BuildApk/>`.
* The `<BundleToolBuildApkSet/>` and `<BundleToolInstallApkSet/>`
  tasks run instead of `adb install`. These are somewhat odd, but they
  use the attached device to decide which format APK set is needed.
  Otherwise the APK set was 200MB!

Some notes about Android App Bundles:

* App bundles use `android:extractNativeLibs="false"`, unless the
  target device's API level is too low.
* `$(AndroidUseAapt2)` is required.
* `$(EmbedAssembliesIntoApk)` is required.
* `$(_EmbeddedDSOsEnabled)` is required, regardless of
  `android:extractNativeLibs` value in `AndroidManifest.xml`.
* `$(AndroidUseApkSigner)` is turned off.
* `$(AndroidUseSharedRuntime)` is turned off.

~~ Java.Interop ~~

Some changes are needed in `MonoRuntimeProvider.Bundled.java` in
java.interop before we can merge this.

We need the "split apks" to be in the list of APKs by calling
`ApplicationInfo.splitPublicSourceDirs`:

https://developer.android.com/reference/android/content/pm/ApplicationInfo.html#splitPublicSourceDirs
jonathanpeppers added a commit to jonathanpeppers/xamarin-android that referenced this issue Mar 22, 2019
Context: xamarin#2727

This is a prototype that gets us this far:

* We generate a `.aab` file
* We can generate a `.apks` file specific for an attached device
* We can *install* the `.apks` file
* The app starts successfully!

This workflow is achieved by:

* The `<Aapt2Link/>` MSBuild task needs to pass `--proto-format`.
* The `<AppBundleBaseZip/>` and `<BundleToolBuildBundle/>` MSBuild
  tasks run instead of `<BuildApk/>`.
* The `<BundleToolBuildApkSet/>` and `<BundleToolInstallApkSet/>`
  tasks run instead of `adb install`. These are somewhat odd, but they
  use the attached device to decide which format APK set is needed.
  Otherwise the APK set was 200MB!

Some notes about Android App Bundles:

* App bundles use `android:extractNativeLibs="false"`, unless the
  target device's API level is too low.
* `$(AndroidUseAapt2)` is required.
* `$(EmbedAssembliesIntoApk)` is required.
* `$(_EmbeddedDSOsEnabled)` is required, regardless of
  `android:extractNativeLibs` value in `AndroidManifest.xml`.
* `$(AndroidUseApkSigner)` is turned off.
* `$(AndroidUseSharedRuntime)` is turned off.

~~ Java.Interop ~~

Some changes are needed in `MonoRuntimeProvider.Bundled.java` in
java.interop before we can merge this.

We need the "split apks" to be in the list of APKs by calling
`ApplicationInfo.splitPublicSourceDirs`:

https://developer.android.com/reference/android/content/pm/ApplicationInfo.html#splitPublicSourceDirs
jonathanpeppers added a commit to jonathanpeppers/xamarin-android that referenced this issue Mar 25, 2019
Context: xamarin#2727

This is a prototype that gets us this far:

* We generate a `.aab` file
* We can generate a `.apks` file specific for an attached device
* We can *install* the `.apks` file
* The app starts successfully!

This workflow is achieved by:

* The `<Aapt2Link/>` MSBuild task needs to pass `--proto-format`.
* The `<AppBundleBaseZip/>` and `<BundleToolBuildBundle/>` MSBuild
  tasks run instead of `<BuildApk/>`.
* The `<BundleToolBuildApkSet/>` and `<BundleToolInstallApkSet/>`
  tasks run instead of `adb install`. These are somewhat odd, but they
  use the attached device to decide which format APK set is needed.
  Otherwise the APK set was 200MB!

Some notes about Android App Bundles:

* App bundles use `android:extractNativeLibs="false"`, unless the
  target device's API level is too low.
* `$(AndroidUseAapt2)` is required.
* `$(EmbedAssembliesIntoApk)` is required.
* `$(_EmbeddedDSOsEnabled)` is required, regardless of
  `android:extractNativeLibs` value in `AndroidManifest.xml`.
* `$(AndroidUseApkSigner)` is turned off.
* `$(AndroidUseSharedRuntime)` is turned off.

~~ Java.Interop ~~

Some changes are needed in `MonoRuntimeProvider.Bundled.java` in
java.interop before we can merge this.

We need the "split apks" to be in the list of APKs by calling
`ApplicationInfo.splitPublicSourceDirs`:

https://developer.android.com/reference/android/content/pm/ApplicationInfo.html#splitPublicSourceDirs
jonathanpeppers added a commit to jonathanpeppers/xamarin-android that referenced this issue Mar 25, 2019
Context: xamarin#2727

This is a prototype that gets us this far:

* We generate a `.aab` file
* We can generate a `.apks` file specific for an attached device
* We can *install* the `.apks` file
* The app starts successfully!

This workflow is achieved by:

* The `<Aapt2Link/>` MSBuild task needs to pass `--proto-format`.
* The `<AppBundleBaseZip/>` and `<BundleToolBuildBundle/>` MSBuild
  tasks run instead of `<BuildApk/>`.
* The `<BundleToolBuildApkSet/>` and `<BundleToolInstallApkSet/>`
  tasks run instead of `adb install`. These are somewhat odd, but they
  use the attached device to decide which format APK set is needed.
  Otherwise the APK set was 200MB!

Some notes about Android App Bundles:

* App bundles use `android:extractNativeLibs="false"`, unless the
  target device's API level is too low.
* `$(AndroidUseAapt2)` is required.
* `$(EmbedAssembliesIntoApk)` is required.
* `$(_EmbeddedDSOsEnabled)` is required, regardless of
  `android:extractNativeLibs` value in `AndroidManifest.xml`.
* `$(AndroidUseApkSigner)` is turned off.
* `$(AndroidUseSharedRuntime)` is turned off.

~~ Java.Interop ~~

Some changes are needed in `MonoRuntimeProvider.Bundled.java` in
java.interop before we can merge this.

We need the "split apks" to be in the list of APKs by calling
`ApplicationInfo.splitPublicSourceDirs`:

https://developer.android.com/reference/android/content/pm/ApplicationInfo.html#splitPublicSourceDirs
jonathanpeppers added a commit to jonathanpeppers/xamarin-android that referenced this issue Apr 1, 2019
Context: xamarin#2727

This is a prototype that gets us this far:

* We generate a `.aab` file
* We can generate a `.apks` file specific for an attached device
* We can *install* the `.apks` file
* The app starts successfully!

This workflow is achieved by:

* The `<Aapt2Link/>` MSBuild task needs to pass `--proto-format`.
* The `<AppBundleBaseZip/>` and `<BundleToolBuildBundle/>` MSBuild
  tasks run instead of `<BuildApk/>`.
* The `<BundleToolBuildApkSet/>` and `<BundleToolInstallApkSet/>`
  tasks run instead of `adb install`. These are somewhat odd, but they
  use the attached device to decide which format APK set is needed.
  Otherwise the APK set was 200MB!

Some notes about Android App Bundles:

* App bundles use `android:extractNativeLibs="false"`, unless the
  target device's API level is too low.
* `$(AndroidUseAapt2)` is required.
* `$(EmbedAssembliesIntoApk)` is required.
* `$(_EmbeddedDSOsEnabled)` is required, regardless of
  `android:extractNativeLibs` value in `AndroidManifest.xml`.
* `$(AndroidUseApkSigner)` is turned off.
* `$(AndroidUseSharedRuntime)` is turned off.

~~ MonoRuntimeProvider ~~

Some changes were needed in `MonoRuntimeProvider.Bundled.java` in
java.interop to move some Java source files to this repo:

xamarin/java.interop#422

We need the "split apks" to be in the list of APKs by calling
`ApplicationInfo.splitPublicSourceDirs`:

https://developer.android.com/reference/android/content/pm/ApplicationInfo.html#splitPublicSourceDirs

These are supported on API 21 and higher, so I had to create 4 `.java`
files:

* `MonoRuntimeProvider.Bundled.java`
* `MonoRuntimeProvider.Bundled.20.java`
* `MonoRuntimeProvider.Shared.java`
* `MonoRuntimeProvider.Shared.20.java`

I also extracted `MonoRuntimeProvider.Shared*.java` in
`_AddStaticResources`. We should remove the equivalent in monodroid,
to keep the code that *extracts* this file in the same repo.
jonathanpeppers added a commit to jonathanpeppers/xamarin-android that referenced this issue Apr 2, 2019
Context: xamarin#2727

This is a prototype that gets us this far:

* We generate a `.aab` file
* We can generate a `.apks` file specific for an attached device
* We can *install* the `.apks` file
* The app starts successfully!

This workflow is achieved by:

* The `<Aapt2Link/>` MSBuild task needs to pass `--proto-format`.
* The `<BuildBaseAppBundle/>` and `<BuildAppBundle/>` MSBuild tasks
  run instead of `<BuildApk/>`.
* The `<BuildApkSet/>` and `<InstallApkSet/>` tasks run instead of
  `adb install`. These are somewhat odd, but they use the attached
  device to decide which format APK set is needed. Otherwise the APK
  set was 200MB!

Some notes about Android App Bundles:

* App bundles use `android:extractNativeLibs="false"`, unless the
  target device's API level is too low.
* `$(AndroidUseAapt2)` is required.
* `$(EmbedAssembliesIntoApk)` is required.
* `$(_EmbeddedDSOsEnabled)` is required, regardless of
  `android:extractNativeLibs` value in `AndroidManifest.xml`.
* `$(AndroidUseApkSigner)` is turned off.
* `$(AndroidUseSharedRuntime)` is turned off.

~~ MonoRuntimeProvider ~~

Some changes were needed in `MonoRuntimeProvider.Bundled.java` in
java.interop to move some Java source files to this repo:

xamarin/java.interop#422

We need the "split apks" to be in the list of APKs by calling
`ApplicationInfo.splitPublicSourceDirs`:

https://developer.android.com/reference/android/content/pm/ApplicationInfo.html#splitPublicSourceDirs

These are supported on API 21 and higher, so I had to create 4 `.java`
files:

* `MonoRuntimeProvider.Bundled.java`
* `MonoRuntimeProvider.Bundled.20.java`
* `MonoRuntimeProvider.Shared.java`
* `MonoRuntimeProvider.Shared.20.java`

I also extracted `MonoRuntimeProvider.Shared*.java` in
`_AddStaticResources`. We should remove the equivalent in monodroid,
to keep the code that *extracts* this file in the same repo.

I also removed `Xamarin.Android.Platform`, which is a dead package we
don't need code for anymore.
jonathanpeppers added a commit to jonathanpeppers/xamarin-android that referenced this issue Apr 4, 2019
Context: xamarin#2727

This is a prototype that gets us this far:

* We generate a `.aab` file
* We can generate a `.apks` file specific for an attached device
* We can *install* the `.apks` file
* The app starts successfully!

This workflow is achieved by:

* The `<Aapt2Link/>` MSBuild task needs to pass `--proto-format`.
* The `<BuildBaseAppBundle/>` and `<BuildAppBundle/>` MSBuild tasks
  run instead of `<BuildApk/>`.
* The `<BuildApkSet/>` and `<InstallApkSet/>` tasks run instead of
  `adb install`. These are somewhat odd, but they use the attached
  device to decide which format APK set is needed. Otherwise the APK
  set was 200MB!

Some notes about Android App Bundles:

* App bundles use `android:extractNativeLibs="false"`, unless the
  target device's API level is too low.
* `$(AndroidUseAapt2)` is required.
* `$(EmbedAssembliesIntoApk)` is required.
* `$(_EmbeddedDSOsEnabled)` is required, regardless of
  `android:extractNativeLibs` value in `AndroidManifest.xml`.
* `$(AndroidUseApkSigner)` is turned off.
* `$(AndroidUseSharedRuntime)` is turned off.

~~ MonoRuntimeProvider ~~

Some changes were needed in `MonoRuntimeProvider.Bundled.java` in
java.interop to move some Java source files to this repo:

xamarin/java.interop#422

We need the "split apks" to be in the list of APKs by calling
`ApplicationInfo.splitPublicSourceDirs`:

https://developer.android.com/reference/android/content/pm/ApplicationInfo.html#splitPublicSourceDirs

These are supported on API 21 and higher, so I had to create 4 `.java`
files:

* `MonoRuntimeProvider.Bundled.java`
* `MonoRuntimeProvider.Bundled.20.java`
* `MonoRuntimeProvider.Shared.java`
* `MonoRuntimeProvider.Shared.20.java`

I also extracted `MonoRuntimeProvider.Shared*.java` in
`_AddStaticResources`. We should remove the equivalent in monodroid,
to keep the code that *extracts* this file in the same repo.

I also removed `Xamarin.Android.Platform`, which is a dead package we
don't need code for anymore.
jonpryor added a commit that referenced this issue Apr 9, 2019
Context: #2727

Initial support for [Android App Bundles][0], which is a new
publishing format for Google Play.

This is a prototype that gets us this far:

  * We generate a `.aab` file
  * We can generate an `.apks` file specific for an attached device
  * We can *install* the `.apks` file
  * The app starts successfully!

This workflow is achieved by:

  * The `<Aapt2Link/>` MSBuild task needs to pass `--proto-format`.
  * The `<BuildBaseAppBundle/>` and `<BuildAppBundle/>` MSBuild tasks
    run instead of `<BuildApk/>`.
  * The `<BuildApkSet/>` and `<InstallApkSet/>` tasks run instead of
    `adb install`.  These are somewhat odd, but they use the attached
    device to decide which format APK set is needed.  Otherwise the
    `.apk` set was 200MB!

Some notes about Android App Bundles:

  * App bundles use `android:extractNativeLibs="false"`, unless the
    target device's API level is too low.
  * `$(AndroidUseAapt2)` is required.
  * `$(EmbedAssembliesIntoApk)` is required.
  * `$(_EmbeddedDSOsEnabled)` is required, regardless of
    `android:extractNativeLibs` value in `AndroidManifest.xml`.
  * `$(AndroidUseApkSigner)` is turned off.
  * `$(AndroidUseSharedRuntime)` is turned off.


~~ MonoRuntimeProvider ~~

Some changes were needed in `MonoRuntimeProvider.Bundled.java` in
Java.Interop (7234e00) to move some Java source files to this repo.

We need the "split apks" to be in the list of APKs by using
[`ApplicationInfo.splitPublicSourceDirs`][1].  These are supported on
API-21 and higher, so I had to create 4 `.java` files:

  * `MonoRuntimeProvider.Bundled.java`
  * `MonoRuntimeProvider.Bundled.20.java`
  * `MonoRuntimeProvider.Shared.java`
  * `MonoRuntimeProvider.Shared.20.java`

I also extracted `MonoRuntimeProvider.Shared*.java` in
`_AddStaticResources`.  We should remove the equivalent in monodroid,
to keep the code that *extracts* this file in the same repo.

I also removed `Xamarin.Android.Platform`, which is a dead package we
don't need code for anymore.

[0]: https://developer.android.com/platform/technology/app-bundle/
[1]: https://developer.android.com/reference/android/content/pm/ApplicationInfo.html#splitPublicSourceDirs
@zijianhuang

This comment has been minimized.

Copy link

commented May 21, 2019

Hopefully this will be released before August 2019 since Google Play had demanded all apps to support 64 bit natively before August.

@tomcurran

This comment has been minimized.

Copy link

commented May 31, 2019

Thanks for progressing @jonathanpeppers @jonpryor

@jonathanpeppers

This comment has been minimized.

Copy link
Member

commented May 31, 2019

We can probably close this when this one is merged: #3146

We are hoping we can get this in a preview soon. We should have a blog post explaining how to try it when it's ready, thanks!

@dansiegel

This comment has been minimized.

Copy link

commented Jun 5, 2019

@jonathanpeppers it seems that PR is merged... is there a way we can try this out? I know Google seems to be complaining about this for an app I'm trying to get into beta. Would love to be able to use this in my CI process even if it means installing a CI/Alpha SDK on the build host.

@dellis1972

This comment has been minimized.

Copy link
Contributor

commented Jun 5, 2019

@dansiegel you should be able to download a visx from our CI system via the Build Status section of our README.md (see https://github.com/xamarin/xamarin-android#build-status) and then picking a Job and going to the Azure Artifacts page. Or just use this to get the latest stable build https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/lastStableBuild/Azure/

Note that these will be the Open Source bits only. So some things (like fast deployment) won't work. But if you are building a release app that should be ok.

@dellis1972

This comment has been minimized.

Copy link
Contributor

commented Jun 26, 2019

@Dooks123 I believe 2017 is in "maintenance mode" which means it gets security related fixes only. So if you want to use this new feature you will need to migrate to VS2019.

That said, the six installer we produce as part of our build system might install against VS 2017. You might want to try to give that a go https://github.com/xamarin/xamarin-android#downloads

@jonathanpeppers

This comment has been minimized.

Copy link
Member

commented Jun 26, 2019

If you want to try out Android App Bundles today;

  • Install the latest VS 2019 Preview, you will need at least Xamarin.Android 9.4.0.34
  • Edit your Android app's .csproj file, adding <AndroidPackageFormat> to your Release configuration:
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    ...
    <AndroidPackageFormat>aab</AndroidPackageFormat>
  </PropertyGroup>

I would not recommend adding this to your Debug builds, since creating/deploying an App Bundle is significantly slower than an APK.

From here you can just deploy in the IDE to test things locally; this will use the default debug keystore file. You'll find the App Bundle in:

bin\Release\com.yourcompany.yourapp-Signed.aab

If you want to distribute the App Bundle on Google Play for testing, you can configure signing in your csproj file as usual:

<AndroidKeyStore>True</AndroidKeyStore>
<AndroidSigningKeyStore>foo.keystore</AndroidSigningKeyStore>
<AndroidSigningStorePass>foo</AndroidSigningStorePass>
<AndroidSigningKeyAlias>foo</AndroidSigningKeyAlias>
<AndroidSigningKeyPass>foo</AndroidSigningKeyPass>

For an extended description of these, see the Microsoft Docs.

Or if you need to do this on CI, these can be set command-line:

msbuild YourApp.Android.csproj /t:SignAndroidPackage /p:Configuration=Release /p:AndroidKeyStore=True /p:AndroidSigningKeyStore=foo.keystore /p:AndroidSigningStorePass=foo /p:AndroidSigningKeyAlias=foo /p:AndroidSigningKeyPass=foo

We are working on the publishing workflows, so will be able to do this from the IDE in future releases.

Open new Github issues if you run into any problems.

If anyone has screenshots of the size savings in their app, please post here -- or @ me on twitter, thanks!

@toruiwatani

This comment has been minimized.

Copy link

commented Jul 10, 2019

Hi @jonathanpeppers,

I'm tested a clear instalation of vs2019 version 16.2 preview 3.0 and cannot create an aab output. When i try to Archive the project Xamarin output sais:

Archiving App Bundle 'AIV.Mobile.Android'...
Creating archive directory 'AIV.Mobile.Android'...
Creating directory 'C:\Users\xxxx\AppData\Local\Xamarin\Mono for Android\Archives\2019-07-10\AIV.Mobile.Android 7-10-19 6.34 PM.apkarchive'...
Deleting files '*.apk'...
Packaging 'AIV.Mobile.Android'...
Creating metadata 'AIV.Mobile.Android'...
Copying icons 'AIV.Mobile.Android'...
Creating directory 'app-icons'...
Copying drawable icons...
Copying mipmap icons...
Copying apks 'AIV.Mobile.Android'...
Copying mdbs and mSYM files for 'AIV.Mobile.Android'...
Invalid Android Archive (no .APK files)
Failed to create App archive 'AIV.Mobile.Android'.

If i remove the <AndroidPackageFormat>aab</AndroidPackageFormat> tag, the Archive command found ok.

vs

@Dooks123

This comment has been minimized.

Copy link

commented Jul 11, 2019

From here you can just deploy in the IDE to test things locally; this will use the default debug keystore file.

@toruiwatani Did you try to use Deploy instead of Archive?

@dellis1972

This comment has been minimized.

Copy link
Contributor

commented Jul 11, 2019

@toruiwatani my guess is the IDE is expecting to see an .apk when the archive command it run. They have some additional code in the IDE's which probably needs updating to take aab files into account.

//cc @joj

@toruiwatani

This comment has been minimized.

Copy link

commented Jul 11, 2019

From here you can just deploy in the IDE to test things locally; this will use the default debug keystore file.

@toruiwatani Did you try to use Deploy instead of Archive?

Hi @Dooks123,

Deploy's not generate any aab file. It's only installs the apk in the phone or emulator.

@toruiwatani

This comment has been minimized.

Copy link

commented Jul 11, 2019

@toruiwatani my guess is the IDE is expecting to see an .apk when the archive command it run. They have some additional code in the IDE's which probably needs updating to take aab files into account.

//cc @joj

Hi @dellis1972,

Ok, but how i can generate aab file? i'm building the app in release config mode and the output (bin\Release) only generates *.dll. The only action thats generates an aab file is Archive or exist another command?

@dellis1972

This comment has been minimized.

Copy link
Contributor

commented Jul 11, 2019

from the command line you can call

msbuild <csproj> /t:SignAndroidPackage /p:Configuration=Release

and if your project is setup for aab that will build one for you and sign it. you can then upload that output to google play.
You can also do

msbuild <csproj> /t:SignAndroidPackage /p:Configuration=Release /p: AndroidPackageFormat=aab
@EmilAlipiev

This comment has been minimized.

Copy link

commented Jul 29, 2019

after uploading app bundle to play store, I get this error message "You can't roll out this release because it doesn't allow any existing users to upgrade to the newly added APKs.". anyone else seeing it? It doesn't allow me to release it, although I am trying this on "closed beta track", not sure if it can be related

@EmilAlipiev

This comment has been minimized.

Copy link

commented Jul 29, 2019

Beside that my app bundle shows that app install size is 22.3-24mb size. my apk size is also 24mb. it doesn't seem that I didn't gain anything. I expected at least, I gain some size from the translations. because I have 6 languages with 6 resx files, a lot of translations. So my question, is there any guide to adjust that user gets only his OS language. and even how about temporary data handling. is there any guide for those in xamarin or we just create abb based on Abis so far?

@dellis1972

This comment has been minimized.

Copy link
Contributor

commented Jul 29, 2019

The google play tooling will not know anything about .net assemblies since its designed to work with java and resources. So I assume it will include all the resx assemblies in the final package.

@jonathanpeppers are you aware of any way of letting the app bundle tooling know what files are for specific cultures? I suspect that kind of thing would be very helpful when shipping games for example.

I suspect this might be part of the "dynamic feature" stuff which we cannot implement yet as it will require changes to the mono runtime to support it.

We should create a test app and see what we can to with the root directory and see if there is a way to package the language resources in such a way that they will not always be included.

[1] https://developer.android.com/guide/app-bundle/
[2] https://developer.android.com/studio/command-line/bundletool

@jonathanpeppers

This comment has been minimized.

Copy link
Member

commented Jul 29, 2019

App Bundles will split up by culture, dpi, etc. for AndroidResource files. I don't think they have ways to declare custom files as another language. Dynamic Feature Modules are probably the only way to do that, which we don't support yet.

I would also guess that @EmilAlipiev is only shipping 1 ABI in the app? I seems odd to not have any size improvement, because all of our so files should be getting split up.

@EmilAlipiev

This comment has been minimized.

Copy link

commented Jul 29, 2019

@jonathanpeppers i usually split apks per abi and each are around 24 mb but aab is around 80mb once i uploaded to google play store, it shows that app install size is 22.3-24mb size for different resolutions.

@andrew1d

This comment has been minimized.

Copy link

commented Aug 1, 2019

Hi I need some help and ill try to explain as much as i can as im new to all this and new to coding.
So i have this script and I really need to make it an .aab file with visual studio.

I have downloaded the preview that was mentioned above.
I have edited the csproj file and input <AndroidPackageFormat>aab</AndroidPackageFormat>
and i get errors and failed to compile.

So i tried using the nuget package manager console (think this is the command line your talking about) and i input msbuild <csproj> /t:SignAndroidPackage /p:Configuration=Release
and it returned with the error

At line:1 char:9

  • msbuild /t:SignAndroidPackage /p:Configuration=Release /p: A ...
  •     ~
    

The '<' operator is reserved for future use.

Is there a step by step instruction as i may seem to be missing something and I'm in desperate need of help.

Heres two screenshots
download (6)

download (5)

So you can see what versions etc i am on.

@andrew1d

This comment has been minimized.

Copy link

commented Aug 1, 2019

Hi I need some help and ill try to explain as much as i can as im new to all this and new to coding.
So i have this script and I really need to make it an .aab file with visual studio.

I have downloaded the preview that was mentioned above.
I have edited the csproj file and input <AndroidPackageFormat>aab</AndroidPackageFormat>
and i get errors and failed to compile.

So i tried using the nuget package manager console (think this is the command line your talking about) and i input msbuild <csproj> /t:SignAndroidPackage /p:Configuration=Release
and it returned with the error

At line:1 char:9

  • msbuild /t:SignAndroidPackage /p:Configuration=Release /p: A ...
  •     ~
    

The '<' operator is reserved for future use.

Is there a step by step instruction as i may seem to be missing something and I'm in desperate need of help.

Heres two screenshots
download (6)

download (5)

So you can see what versions etc i am on.

Update: So i have managed to sort out the command line side of things however when i run the commands such as:
msbuild myapp.csproj /t:SignAndroidPackage /p:Configuration=Release /p: AndroidPackageFormat=aab

or
msbuild QuickDate.csproj /t:SignAndroidPackage /p:Configuration=Release

I get a lot of errors which i dont get in the normal visual studio when building an apk.

@dellis1972

This comment has been minimized.

Copy link
Contributor

commented Aug 1, 2019

You will need to add /restore to the command if you are using Nuget packages.

msbuild /restore myapp.csproj /t:SignAndroidPackage /p:Configuration=Release /p:AndroidPackageFormat=aab
@andrew1d

This comment has been minimized.

Copy link

commented Aug 1, 2019

You will need to add /restore to the command if you are using Nuget packages.

msbuild /restore myapp.csproj /t:SignAndroidPackage /p:Configuration=Release /p: AndroidPackageFormat=aab

Hi dellis1972
Thanks ever so much for the reply its really much appreciated.

When i run that command i get this error:
MSBUILD : error MSB1005: Specify a property and its value.
Switch: /p:

Im not sure what that actually means?

@jonathanpeppers

This comment has been minimized.

Copy link
Member

commented Aug 1, 2019

@andrew1d there should not be a space after /p:

@andrew1d

This comment has been minimized.

Copy link

commented Aug 1, 2019

@jonathanpeppers
Hi Jonathan.
Thanks for your reply matey its really appreciated, so i went ahead and removed the space and now im getting errors like this:

"C:\Users\User\Downloads\Compressed\My App\appmy\myappp.csproj" (SignAndroidPackage target) (1:7) ->
(_CompileResources target) ->
Resources\values-ar\strings.xml(4): error APT0000: duplicate value for resource 'string/Lbl_WorkStatus' with config 'ar'. [C:\Users\User\Downloads\Compressed\My App\appmy\myappp.csproj]
Resources\values-ar\strings.xml(4): error APT0000: resource previously defined here. [C:\Users\User\Downloads\Compressed\My App\appmy\myappp.csproj]
Resources\values-ar\strings.xml(4): error APT0000: duplicate value for resource 'string/Lbl_Users' with config 'ar'. [C:\Users\User\Downloads\Compressed\My App\appmy\myappp.csproj]
Resources\values-ar\strings.xml(4): error APT0000: resource previously defined here. [C:\Users\User\Downloads\Compressed\My App\appmy\myappp.csproj]
Resources\values-ar\strings.xml(4): error APT0000: duplicate value for resource 'string/Lbl_Likes' with config 'ar'. [C:\Users\User\Downloads\Compressed\My App\appmy\myappp.csproj]
Resources\values-ar\strings.xml(4): error APT0000: resource previously defined here. [C:\Users\User\Downloads\Compressed\My App\appmy\myappp.csproj]
Resources\values-ar\strings.xml(4): error APT0000: duplicate value for resource 'string/Lbl_Message' with config 'ar'. [C:\Users\User\Downloads\Compressed\My App\appmy\myappp.csproj]
Resources\values-ar\strings.xml(4): error APT0000: resource previously defined here. [C:\Users\User\Downloads\Compressed\My App\appmy\myappp.csproj]
Resources\values-ar\strings.xml(4): error APT0000: duplicate value for resource 'string/Lbl_Logout' with config 'ar'. [C:\Users\User\Downloads\Compressed\My App\appmy\myappp.csproj]
Resources\values-ar\strings.xml(4): error APT0000: resource previously defined here. [C:\Users\User\Downloads\Compressed\My App\appmy\myappp.csproj]
Resources\values-ar\strings.xml(4): error APT0000: duplicate value for resource 'string/Lbl_DeleteAccount' with config 'ar'. [C:\Users\User\Downloads\Compressed\My App\appmy\myappp.csproj]
Resources\values-ar\strings.xml(4): error APT0000: resource previously defined here. [C:\Users\User\Downloads\Compressed\My App\appmy\myappp.csproj]
Resources\values-ar\strings.xml : error APT0000: file failed to compile. [C:\Users\User\Downloads\Compressed\My App\appmy\myappp.csproj]
Resources\values-de\strings.xml(4): error APT0000: duplicate value for resource 'string/Lbl_WorkStatus' with config 'de'. [C:\Users\User\Downloads\Compressed\My App\appmy\myappp.csproj]
Resources\values-de\strings.xml(4): error APT0000: resource previously defined here. [C:\Users\User\Downloads\Compressed\My App\appmy\myappp.csproj]
Resources\values-de\strings.xml(4): error APT0000: duplicate value for resource 'string/Lbl_Users' with config 'de'. [C:\Users\User\Downloads\Compressed\My App\appmy\myappp.csproj]
Resources\values-de\strings.xml(4): error APT0000: resource previously defined here. [C:\Users\User\Downloads\Compressed\My App\appmy\myappp.csproj]
Resources\values-de\strings.xml(4): error APT0000: duplicate value for resource 'string/Lbl_Likes' with config 'de'. [C:\Users\User\Downloads\Compressed\My App\appmy\myappp.csproj]
Resources\values-de\strings.xml(4): error APT0000: resource previously defined here. [C:\Users\User\Downloads\Compressed\My App\appmy\myappp.csproj]
Resources\values-de\strings.xml(4): error APT0000: duplicate value for resource 'string/Lbl_Message' with config 'de'. [C:\Users\User\Downloads\Compressed\My App\appmy\myappp.csproj]

8 Warning(s)
20 Error(s)

Which i dont understand simply because if i remove the aab and archive it to make an APK then it works fine but when i put aab in my csproj file and run the command you sent me from command line i get those errors,

So any clue on what i can do with this?

@meliheran

This comment has been minimized.

Copy link

commented Aug 15, 2019

I can't believe or something must be wrong ?!

I just started to learn and use Xamarin.Forms and tried to publish my first app in IOS and Android even in WatchOS.

On this journey there were lot of work and problem. Even lot of people told me that choosing Xamarin platform totally wrong choice, I struggled and come to end.

Everything works in development environment.

I just tried to publish IOS app using AppCenter and hit the wall. No Provisioning supported for IOS extension and this support in roadmap... So I gave up and take a break and tried to publish Android app.

AppCenter has a suprise again, can't publish first app using AppCenter. It OK.
Then tried to publish my Android app using Google Console and hit second wall. Error: UnOptimized APK.

And today I learned that Android Bundle does not supported by Xamarin yet.

Well all these are real ?
Or really I do something wrong?

All these path, spend weeks are trash ?

Could you please tell me what is wrong ? What is my fault ?

@jonathanpeppers

This comment has been minimized.

Copy link
Member

commented Aug 15, 2019

@meliheran if you are having issues with App Center, file bug reports with them: https://docs.microsoft.com/en-us/appcenter/general/support-center

This repository is for Xamarin.Android issues, which you can file here: https://github.com/xamarin/xamarin-android/issues

We'll need more information such as logs, etc. if you file one, thanks!

@dansiegel

This comment has been minimized.

Copy link

commented Aug 15, 2019

@meliheran don't confuse your lack of understanding something with something not being possible. For instance it is very much possible to create App Bundles today and to upload them to Google Play. I should know as I've already done it.

@jrahma

This comment has been minimized.

Copy link

commented Aug 19, 2019

I am also having the same problem.

Invalid Android Archive (no .APK files)

I am on 16.2.2 and having the same problem.

I tried removing:

<AndroidPackageFormat>aab</AndroidPackageFormat>

and it works for the archive but then Google Play throws this error when uploading the apk file:

You uploaded an APK that is not zip aligned. You will need to run a zip align tool on your APK and upload it again.

This problem happened recently only when I updated the VS.

Please help..

@AntvissMedia

This comment has been minimized.

Copy link

commented Aug 19, 2019

@jrahma I've just had that earlier. Test AAB yesterday and all was fine. But had to do a quick apk build and saw that error while archiving.

Removed the line you did and then had to close the project and remove the bin and obj files. Cleaned/build/archive... Google.play was very happy and no errors.

Try to remove the folders above and clean the project properly before building and archiving back to apk and see how you get on.

Best of luck!

@AntvissMedia

This comment has been minimized.

Copy link

commented Aug 19, 2019

after uploading app bundle to play store, I get this error message "You can't roll out this release because it doesn't allow any existing users to upgrade to the newly added APKs.". anyone else seeing it? It doesn't allow me to release it, although I am trying this on "closed beta track", not sure if it can be related

You need to make sure that the app version code is higher than all releases in all tracks not just internal.

When you build apks for each ABI, a 1 or 2 or 3 etc is prepended to the app version. When you build an aab that doesn't happen so the version is automatically a lot lower. You can add a 6 in front of your version in the manifest and Google play will see that the version is higher and won't complain.

Hope this helps

@jrahma

This comment has been minimized.

Copy link

commented Aug 19, 2019

properly

@AntvissMedia

  • I removed the line AndroidPackageFormat
  • Closed the project
  • Deleted all obj and bin folders
  • Opened the project
  • Clean
  • Build
  • Archive

file was successfully uploaded Google :)

I'll wait for it to be processed and will update you guys

But that means I had to get rid of the aab :(

Hope there will be a solution for it

@AntvissMedia

This comment has been minimized.

Copy link

commented Aug 19, 2019

@jrahma great news!

Unfortunately, that's correct. It's either one or the other. I'm sure there will come a time very soon when aab will be part of visual studio out of the box and we'll be able to rely on it. For the time being its still in preview and we have to understand that it's not 100% perfect.

I'm happy to say I was able to build AABs for Google play succesfuly 7/9 times I tried. That's a good percentage for a preview functionality. I wouldn't use it for production just yet as it might throw a lot of red herrings when troubleshooting crashes and such. But I'm happy with what the guys did and thank them for it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.