Fixed
Status Update
No update yet.
Comments
ga...@google.com
to...@gmail.com
As a test I removed the exclude part of the abi splits and get the x86_64 and arm68-v8a created but no mips64.
If I enable the universal APK it does correctly contains the missing libs : armeabi, mips, mips64
While I do not have mips users and only continued to build them as it was part of the process I still have some armeabi users
If I enable the universal APK it does correctly contains the missing libs : armeabi, mips, mips64
While I do not have mips users and only continued to build them as it was part of the process I still have some armeabi users
xa...@google.com
armeabi and mips[64] are not default anymore. You need to manually include them
splits {
abi {
enable project.hasProperty("enableAbiSplit")
exclude 'x86_64', 'mips64', 'arm64-v8a'
include 'armeabi', 'mips'
universalApk false
}
}
Adarsh, we need to document this.
splits {
abi {
enable project.hasProperty("enableAbiSplit")
exclude 'x86_64', 'mips64', 'arm64-v8a'
include 'armeabi', 'mips'
universalApk false
}
}
Adarsh, we need to document this.
to...@gmail.com
Thanks effectively pretty simple change :) Just missing a line in changelog.
I took advantage of those test to start looking at adding for 64 bits ABI as it will be required in the future and could not find one information so asking here hoping it's not an issue.
To ensure proper versions installed on devices version codes needs to be ordered correctly.
So arm < armv7 < mips < x86 since x86 provides emulation for armv7.
The question is what about arm64-v8 is there any problem using the order :
arm < armv7 < arm64-v8 < x86 < x86_64 ?
Or is the order forced to be
arm < armv7 < x86 < arm64-v8 < x86_64 ?
I took advantage of those test to start looking at adding for 64 bits ABI as it will be required in the future and could not find one information so asking here hoping it's not an issue.
To ensure proper versions installed on devices version codes needs to be ordered correctly.
So arm < armv7 < mips < x86 since x86 provides emulation for armv7.
The question is what about arm64-v8 is there any problem using the order :
arm < armv7 < arm64-v8 < x86 < x86_64 ?
Or is the order forced to be
arm < armv7 < x86 < arm64-v8 < x86_64 ?
ad...@google.com
ad...@google.com
Yeah, I have a CL in flight for 3.1 stable (cl/188271689). The doc I linked to addresses this behavior change for current 3.1 and 3.2 Preview users.
Because we have been releasing previews for two different version of AS simultaneously, I anticipate there are 3.1 Canary users who jumped over to 3.2 Canary—they would also need to know about this change.
Because we have been releasing previews for two different version of AS simultaneously, I anticipate there are 3.1 Canary users who jumped over to 3.2 Canary—they would also need to know about this change.
ad...@google.com
da...@google.com
Just FYI, the reason arm5, mips, and mips64 are not longer default is because they are not supported in NDK r17. You may want to check the Play Store console and see how many users those APKs are reaching.
to...@gmail.com
Yes I know, but NDK 17 is not yet out and it's usage is unrelated to AS. Some people might want to stay with NDK16.
And as I said I have no mips users I left it there's due to scripts already made, but armv5 are still alive, not a lot (less than 50) and I'll probably drop them in next release to avoid the hassle if I ever migrate to NDK17, but those devices are not dead yet :)
Yes they can't run the latest games but old devices are great as dedicated remotes for example (something that my app can do)
And as I said I have no mips users I left it there's due to scripts already made, but armv5 are still alive, not a lot (less than 50) and I'll probably drop them in next release to avoid the hassle if I ever migrate to NDK17, but those devices are not dead yet :)
Yes they can't run the latest games but old devices are great as dedicated remotes for example (something that my app can do)
xa...@google.com
It's not fully unrelated from Studio. Obviously ABI defaults should be very dynamic and be based on what the NDK contains but due to lack of time we took a more basic approach of hard-coding new defaults, which has drawbacks when using 3.1 and NDK<=16.
to...@gmail.com
IMO defaults should be all and do not build a specific ABI if there's no .so for that.
If a user do not want an ABI he then exclude it. What about aars that includes .so files with users that have never used NDK but do use split ABI.
They're no real reason to change behavior for them.
Really not sure gradle / AS default should rely on future NDK when NDK do not have any version requirement depending on gradle / AS.
Anyway not a big deal when you read changelog, but change still looks strange.
If a user do not want an ABI he then exclude it. What about aars that includes .so files with users that have never used NDK but do use split ABI.
They're no real reason to change behavior for them.
Really not sure gradle / AS default should rely on future NDK when NDK do not have any version requirement depending on gradle / AS.
Anyway not a big deal when you read changelog, but change still looks strange.
Description
Gradle version:
Select File > Project Structure, click Project, and then locate Gradle version.
4.6
Android Plugin Version:
On the same page as the Gradle version, locate Android Plugin Version.
3.1.0-rc0
Module Compile Sdk Version:
From the above page, select your module in the left pane and locate Compile Sdk Version.
27
Module Build Tools Version:
From the above page, locate Build Tools Version.
27.0.3
Android SDK Tools version:
Select Tools > Android > SDK Manager, click SDK Tools, and then locate Android SDK Tools
27.0.3
Since updating to 3.1.0 RC01 using split ABI the APK for armabi and mips are no longer generated. They were ok with beta 4
Related gradle configuration:
splits {
abi {
enable project.hasProperty("enableAbiSplit")
exclude 'x86_64', 'mips64', 'arm64-v8a'
universalApk false
}
}
No error or anything special during build except there's now only 2 APK generated instead of 4