As clearly stated in NDK documentation,
The new .apk will embed your shared libraries, and they will be extracted automatically at installation time by the system when you install the package on a target device.
Now, suppose I included only a subset of all possible libraries, say only the armeabi one. Trying to install on an x86 device will result in the following error:
Installation error: INSTALL_FAILED_CPU_ABI_INCOMPATIBLE
Is it possible to disable platform checking and proceed anyway, since the application is able to fallback to a pure Java implementation of the native code?
My guess would be that it is not, however I believe including a nearly/effectively empty library for other platforms of interest would solve your problem at limited effort or package size impact.
I don't know for a fact that you'd actually need a valid .so for an architecture to pass the test, as opposed to a dummy file in the right folder with the right extension (assuming you never try to load it).
But even if you do need a valid one, you could just build the hello-jni sample for all architectures or something like that. Having a jni function you can call that returns if the library is usable or a stand-in might also be a simple way of solving the detection problem.
Related
I built a dynamic library (and a static) following the guide on https://wiki.openssl.org/index.php/Android
However, I am stuck now and I don't know what to do next.
The next step in the guide is "Install the OpenSSL Library" which I did, and there were no errors. Next step is "Compile and Link against the Library" and I think this is the point where I need help with it, because I have to do it with the Android Studio 2.3.3
How can I make Android Studio 'find' the library and the header files location
Anyone can help?
What you need to do varies on your actual project. Do you have a pointer to your own code?
The best advice I can give is to take a look at a project which also uses NDK. Here is FreeRDP which actually also uses SSL: https://github.com/FreeRDP/FreeRDP/tree/master/client/Android/Studio
You have to wire up stuff, take a look at the .h and .c files here https://github.com/FreeRDP/FreeRDP/tree/master/client/Android
More importantly:
https://github.com/FreeRDP/FreeRDP/blob/master/client/Android/android_jni_callback.h
https://github.com/FreeRDP/FreeRDP/blob/master/client/Android/android_jni_callback.c
https://github.com/FreeRDP/FreeRDP/blob/master/client/Android/android_jni_utils.h
https://github.com/FreeRDP/FreeRDP/blob/master/client/Android/android_jni_utils.c
Follow some of these functions along the codebase. As for SSL in the end it doesn't matter as much how much you install it on your host development environment, but rather it matters how it'll be packaged with the Android app, and how it will be loaded. For example if you use OpenSSL as is, depending on the actual phone it may load the OpenSSL which is part of the system and not what is packaged with the app. https://github.com/FreeRDP/FreeRDP/issues/3631
I have an Android application that only runs on ARM CPUs. This is due to the fact that I have included an ARM executable in the APK. However, after quite a bit of searching, I have been unable to find any way to indicate (in a manifest file or something similar) that the application will not run on other architectures.
Normally, applications that want to include native code include a shared library. In this case, the app only shows up in the Play Store for users with a compatible CPU. However, using a shared library is not an option for my app.
Is there some place in the project's manifest file or somewhere else that I can explicitly indicate the CPU architectures the app supports?
However, using a shared library is not an option for my app.
In theory, it should be. Create a do-nothing little JNI-compatible library with the NDK, and only build it for architectures that your packaged-in binary supports (e.g., ARMv5 and ARMv7). You probably don't even have to use the library (though I'd set up a Java class that references it to be safe, at least during initial testing). That should be enough to trigger Play Store filters, even if you never actually invoke the code at runtime.
IOW, use the NDK stuff just for filtering.
Personally, I'd rewrite your command-line binary to be a NDK-built JNI-compatible library, for performance reasons, but that's just me.
This is may be what you are looking for
TextView tv_showArch_View = (TextView)findViewById(R.id.ShowCPUArch);
String CPU_ABI = Build.CPU_ABI;
tv_showArch_View.setText(CPU_ABI);
It returned to me
ARMeabi for Emulator running on ARM processor
and
X86 for Emulator running on Intel processor
For More detailed information you can go thru Google's Official Documentation
Is there some sort of alternative toolchain or language for Android, which can generate standalone APK files?
Ideally it should not depend on the huge and ever-changing, ever-upgraded official Android SDK.
As a parable, I am looking for a rough equivalent to how PowerBASIC and Mingw targets plain Windows just fine, despite Microsoft releasing new Visual Studios all the time.
Bonus points if this language or toolchain itself is an Android program...
As you may or may not be aware, the Android toolchain is based on a few simple ideas:
Your code is compiled using the plain old java compiler, and linked against the Android stubs (android.jar) for linkage against the system library.
After being compiled, the code is converted to dex format. You can actually run this yourself, just do a dx --help. The job of the dx tool is to take Java class files and convert them to dex code, a pretty straightforward compilation which involves going from a stack based to register based vm, and a few other changes.
After having this in place, an apk is built using a set of apk tools. It used to be apkbuilder, but this has since been deprecated. You can actually run this yourself as well. All an APK is is simply a collection of the manifest, resources, and a single file for all the code in dex form. (I.e., many .class files compile to a single .dex which is quite a bit smaller because of a wrapped web of pointers).
So the Android toolchain isn't really all that complex. The custom build process is handled by ant build rules, which are defined in an SDK wide build.xml, which you can find in the platform-tools/ directory (iirc). However, to generate new baseline projects using this custom build environment you simply use the android update project command.
While I'm not sure if this is the response you'd hoped for, I hope it will disambiguate the build process. It's not really all that complex of a toolchain, the majority of it is off the shelf Java, and not Android specific (all that makes it Android specific is library specific stubs for dynamically linked system code). Beyond this, once you have a set of classes, you need only run a few commands to make an executable APK which Android unpacks. I would suspect that any tool targeting the JVM (and capable of linking with the Android specific dynamically linked API) could perform a similar process of producing class files and using this toolchain to compile the rest of the way, though obviously the automated ant build process makes it much simpler.
EDIT:
After some more digging, I found this relevant android-developers thread. An unsettling quote:
At this time we simply don't have the resources to support people who
want to use their own build system, but we really wish we could. In
many ways we try to make it easy on other tools vendor by clearly
separating logic to eclipse or ant specific code (hence the multitude
of jar files everywhere in the tools and in ADT), but this is not one
of them.
However, you may also find this link helpful.
Terminal-IDE and AIDE are pretty much what I was looking for. Both runs on Android.
I have a feeling I know the answer to this question, but I figure I would see what SO had to say.
I'm hoping to create a console app that can take an .apk file and extract metadata (such as version name/version number). I'm able to use PackageManager.getPackageArchiveInfo() from my Android app just fine, but I'd need to be able to call it from the command line. However, the classes in the android.jar appear to just be stubs, so it doesn't end up working.
Does anyone know of a way to do that?
For apks for which you do not have the signing certificate, you cannot access the contents of the apk beyond seeing that the contents exist.
As you noted, the android.jar is stubs. This is because the android system relies on native code which is designed to run on ARM processors and (probably) wouldn't run on your system. So, they package stub versions of all the java code and the only way to 'run' the actual library is to be executing in a vm with a full version of the android.jar, which would be an ARM environment ( a real handset or a emulator).
There could be ways to setup a 'console' app to do this, but it would have to be communicating with an Android VM to get a working version of the android.jar. I'm guessing that might be more effort than you'd want to sink into this.
I was able to open the .apk file and view it's contents (including AndroidManifest.xml) with WinZip...
'Hope that helps...
I am having too many confusions in native coding for android. My application wants to play mms:// stream and I'm facing some serious problems in that. But the basic question is
What is the difference between ndk-build (that i usually use) and make APP (i have seen many blogs on them one of them is this)
Another related question
Suppose my project is in E:\WorkSpace\mmsTests\AnotherMMS (path edited if you want to test : it contained whitespace)
And my ndk path is D:\android-ndk-r4b-windows\android-ndk-r4b
How can i use make APP with cygwin?
My os is windows xp sp2.
EDIT : I have added ndk location in my PATH variable
Thanks in advance
The 'make APP=...' method was the original NDK build system but is now deprecated in favor of the ndk-build method.
Anything that can be built with make APP=xxx can be built with ndk-build. ndk-build requires less manual setup and hard coded paths.