Is it possible to get multiple APK binaries vary by processor architectures (ARM, X86) in Smartface App Studio? I don't know how can I achieve this situation and upload them to Google Play Store.
About getting multiple apks(ARM and x86), you can check this link :
http://www.smartface.io/developer/guides/project/publishing-procedures/
In order to upload these two apks(with ARM architecture and x86 architecture), you should get publish one by one, not two of them at the same time.
One thing you need to pay attention is that, changing the versionCode value in AndroidManifest.xml.
android:versionCode="1"
The versionCode for x86 must be higher than the one in ARM.
Open AndroidManifest, change the versionCode as it should be(if this is already an application on GooglePlay, then you should now the correct versionCode), for example let's say it is 1.
Get publish for ARM.
Then increment the versionCode by one, it will become 2, and get publish for x86.
At last, you will have 2 apks with different versionCodes.
The second important thing is that, firstly you should upload the apk with x86 structure. After that you can turn to advanced mode and upload the second apk with ARM structure to GooglePlay.
If device can run x86 apk, then it automatically will download the one with x86 architecture. If not, then the apk with ARM architecture will be downloaded.
Related
I would like to know if the apk file produced from running the flutter run --release command is different from flutter build apk. Which is better for uploading to the playstore.? I just tried both commands and the difference in apk size is really huge. The release command produces a far smaller apk size.
In summary what I want to know is since
Flutter build apk =>> fat apk.
Does
Flutter run --release =>> split apk?
flutter run --release: builds a release version of the app and starts it directly, then shows the console UI to manipulate the running instance.source flutter wiki
Use release mode for deploying the app, when you want maximum optimization and minimal footprint size. For mobile, release mode (which is not supported on the simulator or emulator), means that:
Assertions are disabled.
Debugging information is stripped out.
Debugging is disabled.
Compilation is optimized for fast startup, fast execution, and small package sizes.
Service extensions are disabled.
(apps are smaller)
flutter build apk results in a fat which is a single APK that contains binaries for multiple ABIs embedded within it. This has the benefit that the single APK runs on multiple architectures and thus has wider compatibility, but it has the drawback that its file size is much larger, causing users to download and store more bytes when installing your application. When building APKs instead of app bundles, it is strongly recommended to build split APKs
Although app bundles are preferred over APKs, there are stores that don’t yet support app bundles
When should I build app bundles versus APKs?
The Google Play Store recommends that you deploy app bundles over APKs because they allow a more efficient delivery of the application to your users. However, if you’re distributing your application by means other than the Play Store, an APK may be your only option.
read more from the docs
You can split apks with this command
flutter build apk --target-platform android-arm,android-arm64,android-x64 --split-per-abi
I have a Unity project that I'm switching from APKs to AABs (app bundles). Previously, when I was building it as an APK, the Google Play Console told me the APK was 64-bit compliant.
Now that I'm building an aab, I'm getting the warning:
This release is not compliant with the Google Play 64-bit requirement.
The following APKs or App Bundles are available to 64-bit devices, but
they only have 32-bit native code
I have both ARM7 and ARM64 architectures set.
I am excluding x86.
When I open the .aab in an archive viewer, the lib folder has all of
the .so's for both arm64-v8a and armabi-v7a.
I'm using IL2CPP, .NET 4.x
I'm using Unity 2018.3.7f1
My ndk version is 16b
My
Android Studio is up to 3.4.2 and gradle is 3.2
A lot of similar threads here talk about following the "Learn more" links, which I've done. I had already done all of the work to get my app 64-bit compliant before switching to app bundles.
Other threads talk about Android Studio solutions, which I can't use because my automated build process involves building with Unity from command line, so it has to be Unity configurations or bust.
My expectation was the app bundles were supposed to be the hot new way to let Google build better APKs for you, but it seems like it's getting confused on whether or not aabs are actually 64-bit compliant, which seems to defeat the whole purpose.
Is this a Unity problem, does Google have an error in their system with regards to app bundles, or is there some other step I'm missing?
For those who have this problem since yesterday (August 19, 2019):
In Player Settings > Other Settings you must now uncheck the x86 box (It is for the 32-bit Intel architecture).
You will now only have the following warning:
The device types on which your application can be installed will be more restricted.
But, in my case, it drops from 12392 devices to 12385 devices.
Here is the opinion of a Unity member on the issue:
x86 is used by less than 0.4% of all Android devices, so it shouldn't have any real impact.
x86 target will be removed completely in Unity 2019.3.
It looks that there was a bug in the Play Console where this message was displayed even when the AAB was compliant. This should have been fixed last Friday afternoon.
Try again now.
By multiplatform I mean arm64 and arm, using the default way of build a release apk it gives me an apk that works only on arm, but I can make an arm64 version by using the command
flutter build apk --release --target-platform --android-arm
The question is, how to make 1 apk for both platform or an app bundle that will work for play store?
I think is by using:
flutter build appbundle
Currently, if you're uploading an APK to the play store you need to upload multiple APKs for the architectures you're specifically targeting. You're able to create a "fat APK" which contains all the architectures however, it will increase the overall APK size.
As per the docs, it's recommended to use the app bundles as it will provide the required architecture depending on the device that downloads the app.
More info here: https://flutter.dev/docs/deployment/android
use this command in terminal ->flutter build apk --split-per-abi
I have integrate crosswalk plugin in my Cordova application. When I publish this app to google play. I'm not able to open in my Asus gen phone 2 it throws following error
Error message:Mismatch of CPU Architecture for the Crosswalk
Cordova version - 6.0.0
Crosswalk Version - latest
Can any one help me for resolving this problem?
The Asus phones tend to use an Intel x86 chipset. When doing anything with native code, you need to account for the various chipsets used by devices. Crosswalk is built with native code. It sounds like you did not include builds for both the ARM and x86 chipsets to Google play.
The Cordava Crosswalk plugin out-of-the-box will give you 2 chipset builds, 1 for ARM and 1 for x86 CPU architectures. You should be uploading both APK output files to Google Play.
NOTE: Since Google play changed the max APK size from 50mb to 100mb, you now have the option of package both chipsets together. However, you may still want to consider having a separate build for each and uploading them separately.
I have 2 modules in my project Mobile & Wear because I eventually want to add wear support. I have not done any work to the Wear project, it is just whatever Android Studio generates as part of the project creation template.
I noticed Android Studio creates 2 separate APKs when you do a signed build. I see 1 mobile APK and 1 Wear APK upon signed build.
If I would like to publish only the mobile Module now, and Wear later. Do I just upload the Mobile APK and that's it? Or are there any additional config / code changes necessary?
Thanks.
When you're developing, there's two different apk's as you said, because each one is used to test the app while we are developing.
Once that you want to submit your app to the market, these two .apk will become just one, calling this process "packaging wearable app".
So, if you want have just your mobile .apk, please go to build.gradle(mobile), and comment the code:
wearApp project(':wear')
Basically this line is telling to your compiler, to pack your wear app into your mobile app.