Why can't I publish the game? - android

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

Related

Unable to build project with both Firebase and Mapbox

I have created a location-based game using the Mapbox SDK in Unity 2018.2.1f1, and it has been able to build just fine. My goal was to add database functionality to my project by using Firebase, to store GPS coordinates online.
I followed the official tutorial for setting up Firebase in a Unity project. When this was completed, a window popped up saying "Resolving Android Dependencies", which took about half an hour.
Since then, I have been unable to build to my Android device. I receive 96 gradle build error, and the one at the top is:
> No toolchains found in the NDK toolchains folder for ABI with prefix:
mips64el-linux-android"
I reverted the project to its pre-Firebase version, and it was still unable to build, as if something in the Android build tools had been changed.
Next, I tried an entirely different version of Unity, and installed a fresh install of Unity 2019.2.9f1. I opted to use this version of Unity's in-build Android SDK and NDK. I reverted my project back to the last known working version (pre-Firebase), ported it to the new version of Unity, and completed a successful build to my device before moving on.
Then I followed the appropriate steps to add Firebase to my project again, and the same exact pop-up windows appeared in Unity, claiming that it detected "obsolete files" that it wished to delete (this time I said no), and then it performed the same "Resolving Android Dependencies" process.
Once this process was complete, I made no other changes, and tried to build again. It failed, and I received the same 96 gradle build errors. This confirms this error as repeatable on two different versions of Unity.
I believe this has something to do with conflicting dependencies between Mapbox and Firebase. Has anyone encountered this issue, or successfully been able to use these two things together in a project?
So, the baseline problem is that something is telling the Android build process to generate project files for the MIPS architecture. This architecture was removed from the official NDK in r17 (see this link for supported architectures). I'm not sure if Unity ever supported it, but it's not in the current version:
I do not know how MapBox is packaged and shipped, so I don't exactly know what postprocessing hooks might be conflicting between that and Firebase. I'll try to give you some steps forward though.
First, make sure you have the latest SDK from Firebase and MapBox. Also, when it asks to delete obsolete files, say yes. The Play Services Resolver should only prompt this for files that it tracks (and the Firebase plugin ships in a state where this is expected).
If that doesn't help, look for a mips folder included in your Unity project (probably something like libs/mips or jnilibs/mips). Hopefully deleting these will fix the issue.
If the above doesn't work or is non-actionable, try using a mainTemplate.gradle file:
If you follow the instructions I wrote up here to instruct the Play Services Resolver to patch your mainTemplate.gradle file:
You can double check your ABI filters directly in the file. By default it shows:
ndk {
abiFilters **ABIFILTERS**
}
to match what you've selected in Unity. But you can use this to double check that mips64 isn't included via some other process.
Unfortunately I don't know what else to suggest if neither of the above options work. In that case I'd suggest posting a bit more of the error you're getting. If you can reproduce the error you're having with one of the Firebase sample projects, you can file an issue on that issue tracker directly. Finally, if you don't get an answer here and you do think that it's Firebase related, you can contact the Firebase support as well.
I hope something in my post helps!
--Patrick

Targeting 64 bit architectures on Xamarin Android

I received an email from Google that we need to start supporting 64-bit CPUs in our Android apps by August 1, 2019. In their documentation, it states that there should be a lib/arm64-v8a folder in your apk contents if you're correctly supporting 64 bit.
In my Xamarin Project Options > Build > Compiler settings, my Platform target is set to "Any" so I would expect it to build both 32 and 64 bit versions. However, when I generate a release build and package it into an apk, when I browse the apk it only has a lib/armeabi-v7a folder, there is no v8a folder. So what do I need to do to support 64 bit architectures?
EDIT: I should have included this screenshot, showing my Supported ABIs:
Go into your Project settings / Build / Android Build / Advanced and enable arm64-v8a as one of your supported ABIs.
And then do a fresh build (or a new archive if you are using that feature of VS).
Note: Make sure you do this for your Release configuration
As #sushihangover mentioned, you just have to Make Sure that on your "Release" configuration, you need to select the arm64-v8a ABI configuration.
Remember to "Rebuild All" before you hit "Archive for Publishing" so that you don't run into issues based on cached data.
You can view this article for more details and a video.
In my case (after many weeks of frustration), it turns out that Google Play Console (depending on app release setting) may try to 'retain' older versions of your application. You need to remove all older versions during the release.

Is it possible to debug C/C++ in Android Studio?

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.

Android on Desktop tutorials/resources

I'm aware of the android-x86 project and as far as the end result (bootable live/install iso), I am looking to do the same thing. The difference is, I'm looking to do this with the ice cream sandwich branch from android master repo. Ice cream sandwich adds full support for x86 hardware and even sports a build target specifically for running the OS in virtualbox. So my question is, is anyone aware of any documentation for building and deploying to that target?
Just in case it's not clear, I'm not just using the android-x86 project because they haven't yet put up a build for anything later than android 3.
Okay so I was going to just delete my question because a few minutes after posting it, I found a tutorial! So, I figured I'd share this info here rather than just deleting, since that's a bit of a waste. Here is a link, plus an excerpt from the tutorial in case the link is ever lost:
http://ricston.com/blog/?p=1705
The second approach gives you direct access to the latest Android
code. However, it’s barely documented due to the fact that previously
you couldn’t build ‘out of the box’ an Android VDI (Virtual Disk
Image) with the AOSP. To build the Android VDI and install it in your
VM, follow these steps:
Get the Android source code from the AOSP site and follow the online
instructions to setup the environment.
When you are ready to build the project, execute the following command to set the environment variables for Make: “lunch vbox_x86-eng”.
Run “make installer_vdi” to
build the project. Make will build the project and produce a VDI named
“installer.vdi” located in “out/target/product/vbox_x86″. This VDI
contains Android plus its installer.
Create a Linux VM and add the
“installer.vdi” as an extra HD to the VM.
Start the VM and press “F12”
during bootup.
Select the HD which represents the “installer.vdi”.
Choose the first option, that is, “Android Install to /dev/sda from
/dev/sdb”.
When installation is complete, enter the command “reboot”.
After that, you should be able to launch Android from your VM.
I want to expand on this approach and end up producing a live CD rather than a VDI so I'm going to post this answer as a community wiki so it can be expanded by myself and others in the future.
Edit Nov 26/11
The above method of building right from the source alone is lacking features like proper keyboard and mouse support. Here is a link to an article (in Japanese but you can use google translate) of an individual who has compile the ICS sources with added in keyboard, mouse and network support. http://d.hatena.ne.jp/td2sk/20111125/1322192772
The precompiled VDI disk can be downloaded from here:
http://kie.nu/26G

Having a blackberry J2ME and Android Project under Eclipse

I am building a project under netbeans with a lot of preprocessing instructions. Netbeans handle that pretty well but unfortunately it is not very well supported as an IDE for blackberry and android.
So the idea behind this question is to import the project into eclipse in order to get the new features of every plugin and ease the development. I already found a pretty nice solution for handling preprocessing instructions with Antenna, but I would like to know how to handle the multiple facets of the project : an android project with ADT, a blackberry project with its plugin and finally a J2ME project as well. My goal is to taking advantage of the best plugins eclipse has to offer.
(And the project compiles with ant, so no real problem on this side).
Regards,
Stéphane
Well, you would have to create a separate project for each Android, Blackberry etc in the same workspace, then you would have to define the logical dependency between those projects. So if Project A is dependent on Project B, right-click on Project A in the project tree then Properties > Java Build Path > Projects and add the Project B to the list of projects Project A depends on.
This will allow you to work on Project B as if it was a stand alone project and you and work on Project A as if Project B was a part of it.
You can do this with any number of projects.
Regards,
get BB eclipse plugin from Blackberry site
install Android ADT manager from developer.android
install j2me wireless toolkit
create all project separately into same work space
use relative sdk for build path
after creating project you can also copy your source files to your project n file system, you can defile project dependency as Ali said
i reccomend to disable pre-processing, if you are using ant to build, just disabele it from windows > preference
My Suggestion to you is build your project in HTML5.If you are targeting the android as well as Blackberry .I do not Know How you will do it but It will be really easy to transform the the application of Blackberry to Android.
You have to install the BlackBerry plugin from the RIM site and it is a huge download that includes Eclipse itself. Then you can add the Android plugin via the Eclipse "Install New Software" menu.
I personally did it on my home machine and here is how How I had done
First install the the Eclipse plugin provided on blackberry developer site
Next install the android in same eclipse from Android developer site.
And voilla you are ready for android and blackberry development on single eclipse. I dont know about J2ME bcoz I no longer works on it but I think the plugin for Eclipse will do the work
This may not be quite what you're looking for but perhaps use Ant to do the builds, packaging etc. That makes it easier to support multiple platforms, set preprocessor macros etc. So the IDE would be used for mostly editing. Note that on BB you can have the IDE refer to the .jar thus resolving dependencies.
I had faced a similar issue. I installed Android first and was working on Google maps project .Since I shifted to Blackberry for a while, when i tried installing that plug-in,it did not accept it. Later after much research I found out that the Emulator for android was supporting Maps which inturn does not support installation of BlackBerry. Pretty weird. Like ber444 mentioned, BB plugin is a huge download file of 402 MB which consists of eclipse 3.5 support.
I was working on Ganneymede for android and installed indigo for BB but its not supported

Categories

Resources