enter image description hereI select arm64 (64 bit) and x86 and amrv7 and select build app bundle in player setting
so but when I want publish so I have an error like :
Error
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: 2.
Include 64-bit and 32-bit native code in your app. Use the Android App Bundle publishing format to automatically ensure that each device architecture receives only the native code it needs. This avoids increasing the overall size of your app.
All plugin worked in my other game but A plug in i new(=applovin sdk), this is a system ads , How can I understand applovin sdk support for 64 bit ?
Why can't I publish the game?
please help me
I have this problem some week and can not publish my games ? please help me
What is my wrong?
Go to project properties, Switch to project back end IL2CPP.
Android project properties -> https://docs.unity3d.com/Manual/class-PlayerSettingsAndroid.html
IL2CPP setting -> https://docs.unity3d.com/Manual/IL2CPP.html
other stuff that you probably already did:
https://docs.unity3d.com/Manual/BuildSettings.html
switch platform -> to Android
ensure you have API compatibility set, and that you have downloaded the required API versions via the Android NPK tooling.
Based on your error you could also try temporarily disabling the ARM7 option.
[update]
Based on OP's response, while the above is general troubleshooting, it seems to be native plugin. If this is the case use the following technique to determine if the plugin is 32 bit.
1. Create a new android project, make sure it builds. set ARM64 and not ARM7 in project settings.
2. add just the plugin. Rebuild the project.
3. If there is an exception related to the platform it may be the plugin is 32 bit.
If you get an error
First check the error, it may not be related (i.e. a red herring).
Go back to the plugin site, check for 64 bit, also check if the plugin has git source such as on GitHub.
If it does you can probably recompile the plugin to 64 bit (separate question).
I know i'm replying a bit late, but i think the solution is to just:
Enable IL2CPP
Disable x86
I'm working on a Xamarin Forms app for Android and iOS. We use a third-party SDK that comes as an .aar package, build action set to LibraryProjectZip. Then, we have calls from the forms, the iOS, and the Android parts of the code. Linking works just fine in debug mode if I remember correctly.
I'm failing to get the Linker+ProGuard work together. I've read for days and experimented with numerous solutions. I was having java codes 1 and 2 - so I updated ProGuard and it started working. Then Linking was producing errors - UnauthorizedAccessException so I had to go to the respective folder and remove the ReadOnly permission. Then the project is built successfully but the app functionality is lost even though it runs and in Device Log I can see that some classes are missing.
To fix that, I created a ProGuard.cfg and added most of the assemblies that were crashing with the "-keep" command. However, I can't seem to find a way to preserve the functionality from this .aar package
Any suggestions?
I'm using VS 2017 and Xamarin 7.4 on Windows 10 with JDK 1.8, running as Administrator. Tried linking Sdk Assemblies / User&Sdk Assemblies. Multidex is on. I've tried putting the names of the assemblies of all the projects in the Skip Linking Assemblies field, no results. In the device log, I get a package name for the call that is failing so I tried adding this to ProGuard too but it didn't help. (it looked like "-keep class com.something.something")
I can't comment, but this blog post may be of use.
"The Linker Analyzer is a command line tool that analyzes dependencies which are recorded during the LinkAssemblies step. It will show you what items were marked and resulted in the linked assembly."
https://www.jon-douglas.com/2017/09/22/linker-analyzer/
I have not migrated my project to Android Studio yet, but I still want to use Fabric/Crashlytics to manage crashes of my app. I am using the Android Developer Tools (ADT) 23.
I tried the Fabrics eclipse plugin and it installs and starts fine. Then I login and the plugin presents a "Select kit to install" dialog. But the buttons are inactive and they only say "checkin...". After a few seconds I am getting the login screen again. I tried a few times it doesnt work that way, since the eclipse plugin is discontinued i guess i can not hope for any support.
So is there a way to download an sdk or a java lib somewhere and perform all the necessary steps myself?
Here is a step by step to do it manually and it seems easy, if your setup has gradle support:
https://www.fabric.io/kits/android/crashlytics/install
But I dont have Android Studio, so the build.gradle is no good to me.
I added a few SDKs and libraries of other companies to my project and I never had so many problems like this.
Maybe someone can aid me to the right path?
I'm writing an Android app that includes C/C++ code that is compiled alongside the Java code. My app is crashing during the execution of the native code.
Is there a way to step through Android C/C++ source and inspect variables as it is possible with Java source?
I am not necessarily looking for a way to step through the source from within Android Studio. That is obviously the ideal solution, however, if I need to use an external tool after starting the app from Studio, that's fine. I want to be able to step through the execution line-by-line and inspect variables.
Android Studio 1.0.2
Android NDK r10d
Edit: Stemming from the immediate response of, "Use Eclipse with ADT plugin", let me add more requirements.
This project started as an Eclipse ADT project. However, I have now migrated to Android Studio. My project is now built using Gradle, and my project directory structure reflects this. I am willing to use Eclipse; I am not willing to change my project structure in order to revert to Eclipse from Android Studio. If there is a way to open the Android Studio project in Eclipse and debug it that way, please elaborate on the process.
[UPDATE]
As of July 2015, Android Studio DOES support NDK.
You can learn more about it on this link.
[OLD]
NDK is not yet supported in Android Studio.
When we have to deal with NDK, the only solution is to use Eclipse.
EDIT
We basically keep Eclipse project with NDK feature (map in our case) and Gradle project with other (non-map) features. So everything that has to be done with NDK, we do in Eclipse and then include changes into Gradle project.
To be more precise, inside directory /src/main/ we created another directory called jniLibs and put the compiled *.so file inside architecture-specific folders (armeabi-v7a, armeabi, x86...). Then in the main class of Gradle project simply added a line
static {
System.loadLibrary("OurNDKLibName");
}
You can add this line only once per project. Maybe I am wrong but we did not have any issues for doing so.
As of version 1.3+ Preview Android Studio supports C++ debugging, quoting Android M Developer Preview & Tools:
Most notable is a much requested feature from our Android NDK & game developers: code editing and debugging for C/C++ code. Based on JetBrains Clion platform, the Android Studio NDK plugin provides features such as refactoring and code completion for C/C++ code alongside your Java code. Java and C/C++ code support is integrated into one development experience free of charge for Android app developers.
It isn't wasn't isn't working very well.
hello-jni fails failed with:
Starting LLDB server: run-as com.example.sample
/data/data/com.example.sample/lldb/bin/start_lldb_server.sh
/data/data/com.example.sample/lldb
/data/data/com.example.sample/lldb/tmp/platform.port1442695333842 "lldb
process:gdb-remote packets"
Error while launching debug server on device:
com.android.tools.ndk.run.DebuggerContext$StartServerException:
java.lang.IllegalStateException: Failed to read platform port
/data/data/com.example.sample/lldb/tmp/platform.port1442695333842
I'm using 1.4RC1
compileSdkVersion 23
buildToolsVersion "23.0.1"
And the "app-native" run configuration #Gerry mentioned. It's nearly there, but I can find no trace of an lldb directory in my app's private data folder. I do find a 400kb gdbserver in the lib directory linked from there, with my own *.so right besides. Unfortunately the option for debugging with gdb instead of lldb has gone with the upgrade from 1.3 to 1.4. NDK 10e ships a 400kb gdbserver binary in ndk\prebuilt\android-arm\gdbserver which it is (I guess). On September 15th the gdb debug howto https://github.com/mapbox/mapbox-gl-native/wiki/Android-debugging-with-remote-GDB was updated. This is harder than logcat debugging IMO, but a current topic, sorry to be so negative but I don't believe lldb actually works yet.
I have run hello-jni and reached the same conclusion.
So in answer to your question, it is not yet possible to debug C/C++ in Android Studio. Sorry this wasn't the answer you hoped for and I hope to be proved wrong with conclusive evidence to the contrary, but right here, right now, no chance!
UPDATE I raised an issue where I was given a fix for one phone.
UPDATE2 Too early to tell, it is experimental after all, but I am occasionally failing to connect, often if not always getting out of order stepping and breakpoints with nonsense parameter values. I just set a conditional breakpoint that didn't fire but the logcat shows it should. Initially I assumed it was my logical error, but it goes deeper.
Simply hitting breakpoints at all is very helpful but it is still a million miles short of Java debugging, or Vis Studio C++ debugging.
UPDATE3 Gone back to stable 1.3.1 as the canaray channel version was pausing for a toilet break every keystroke. While native debug build at least launches with my "fixed" phone, no breakpoints are hit even in hellojni, or a slightly extended version to give more opportunity. I'm used to logcat now but have had better degbugging experiences with Android, NDK and Eclipse. A more elaborate solution is also easier to break, but at least it works.
Yes, Android Studio does support C++ debugging at least with Android studio 1.5.1 and android-ndk-r10e.
In the old days, you will have to write make files Android.mk and Application.mk in order to build the C++ code in Android Studio. You don't need them any more. As long as you put them under the jni folder, gradle will be able to pick it up and compile it. You should see something like the following:
And also allow you to set break point and debug it.
You should follow this step-by-step tutorial and learn more about it. And read more about the documentation here. I've uploaded a complete working example so that you can download and try it out on GitHub.
With Android Studio 1.4 from tools.android.com, debugging is possible. When you open/create a project with C++[jni] code in it, Android studio would create a new configuration, something like $(module_name)-native
I would select this configuration, sync gradle, build, set breakpoint etc and run it with Android Studio. After a long wait, my debugger is connected, app is broken in[I think you could also set breakpoint at this time]; this break is not at my set break points, I let it go in android studio and my breakpoint is hit. Hope this helps
Some samples are supposed to work with android debugger
yes! it is possible to debug native code in android studio. As from the updates Android Studio 2.2+ support in built tools for debugging native code.
I've spent the last few days struggling with getting a system up and running for building multiple configurations of our Android NDK App. I am able to build the libraries fine; the issues I run into usually stem from keeping those libraries up to date when changing build configurations.
I need a system that is for the most part fully automated: the user should just change build configurations and everything just works!
How have you addressed build configurations and the issues with libraries not being properly rebuilt?
I've tried a bunch of different approaches to this, but they all seem to end up with issues that are out of my hands.
Initially we just outputted a Shared Object file with the same name regardless of Build Configuration (eg. game.so). The problem is, changing build configurations doesn't trigger the library to be rebuilt; you have to make a change to the source or build scripts. So people change from Debug to Release, run the app, and are unknowingly actually linking to the Debug version still.
So then we tried outputting the library to a unique Shared Object based on the build configuration. For example, the debug version is gamed.so. The release version is gamer.so. The problem is, the Java code has no concept of build configuration, so how do we know which version of the library to load (which is done from Java)?
Well to get around that we do a try/catch looping through all the possible versions of the library attempting to load them. When we find the one that exists, load it! Problem being that the old versions of the library do not get removed when deploying a new configuration to the phone. So if you have built and run both Debug and Release, both of those libraries are now on the phone! Which ever one you ask for first, it will find and load.
So anyway, this seems like something that must have been solved already, but I have found very little information online. Nothing that has met my needs.
My question is: how have you addressed build configurations and the issues with libraries not being properly rebuilt?
This is actually strange. I have always seen that install -r refreshes the /data/data/app.pack.age/lib directory. Which device do you use for development?