I find shared library(.so) in Android my device. And I want use exports functions from it. But how I understand, I need header files for this library. Where I can find it on device? What dirrectories?
Most probably the headers won't be available on the device.
As they are only needed to link against the library not for running the program normally they aren't contained in the system image on your device.
You might want to take a look into the headers that come with the NDK if the header you are looking for is contained there. (see: http://developer.android.com/tools/sdk/ndk/index.html)
If it isn't it is not part of the libraries google wants you to use as it is not considered to belong to the set of libraries google intends to keep stable.
Nevertheless you'll be able to fetch the required headers from the sources belonging to the android version running on your device in this case. (see: http://source.android.com/)
It might be possible those libraries won't be available any more after the next system upgrade then but that's especially the point about headers and libraries not included.
It's only guarenteed the libraries included in the NDK will available.
Related
I'm developing a native application using C/C++.
I need to use name resolution service.
Making JNI calls is an option.
Using an external native library is another option.
However, I'm thinking about the probability of a third option.
As noted here, on devices running Android 10 and higher, this service is provided with a native library (libnetd_resolv.so).
This means, functions that I need rest in this library and I can confirm that.
My question is, can I use this library dynamically and get name resolution service?
I know that Android doesn't allow applications to use system libraries but what if I download this shared object and distribute with my application*, does it work?
If it doesn't, is there a future plan for this to work?
I'm asking because it is so weird to me that I need a function, it resides in my hands, but I have to make JNI calls in order to use it.
* When I embed the shared object in my application, there may be some compatibility problems when new updates are made to the shared object but that's not the point for me, if it works for one Android release it's ok.
Before attempting to add in a third-party library, do check if the existing Android NDK Networking APIs support your use case.
Do be aware of which versions of Android any particular API is supported.
I'm trying to write a barebones Vulkan app on Android. I'm finding that most of Google's example apps rely on vulkan_wrapper.h and vulkan_wrapper.cpp. Google's Vulkan documentation also says to use them.
I would love to use them but they are part of the example projects' code, not the SDK, and the header says that they are generated. So how is a developer supposed to generate them for their project? I have copied them from a sample app for the time being but am curious what the best practice is for generating them and keeping them up-to-date.
I'm not sure how they're generated, but you could just copy them into your project. There shouldn't be much need to regenerate them, since they only contain the core and WSI extension entrypoints normally provided by libvulkan.so; even if you regenerate it, it won't contain other extensions that might have been added to vulkan.h.
The only reason to use these is if you want to avoid linking against libvulkan.so directly, which only matters if you want your app to load and run on devices that don't have it (Marshmallow and older).
Not sure How they get generated but you can do something like that if you want it to. Vulkan layers come with the scripts and the xml file, you can modify the script to your requirements. We are already doing that in our projects. The script can be found here.
https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/tree/master/scripts
Is there any way to limit Android NDK Library to the Specific JAVA Application ? I would like to prevent programmers from using my lib in another applications.
EDIT
I'm building a shared library that will be used in another application by user(another programmer).
EDIT 2
this library also include a java library that interact with the native library via JNI.
I would like to prevent programmers from using my lib in another applications.
... presumably for copy-protection of some sort.
You didn't say whether the "permitted" application is built by you or by someone else.
If the former, linking your library statically into the application will make it very hard to reuse that library elsewhere.
If the latter, you could use some techniques, such as looking in /proc/self/exe to find application name from within the library and exit if what you see there is not what you allow, but
such techniques will likely cause grief to your customers, and
will increase your support load (when they misfire under legitimate conditions), and
will be trivially bypassed by a moderately sophisticated adversary.
Which is to say that generally that's a waste of time.
I have an Android app that's downloaded primarily from Android Market (now, Google Play). We made a few tweaks to the source and also submitted to the Amazon App Store to see what sort of traction it gets. I'm now looking for a sustainable way to develop from a common code base and yet build so that I can submit to either/both.
Amazon's store has some restrictions about available APIs, and hence I'd like to conditionally remove/modify features from that version. Since Java doesn't support traditional conditional compilation, and conditionally including files in Eclipse doesn't seem trivial (is it even possible?), I wanted to ask what others are doing to solve this.
Admittedly, I'm no Eclipse/Java expert so feel free to school me.
What I'm looking for in a solution:
Building/debugging using Eclipse.
Static code files, with environment/settings toggles to control what to build.
No duplicate code or conditional logic in code to pick code flow at runtime
Is this something you've solved for Android apps specifically, or for other Java/Eclipse based projects? Suggestions for where to begin?
It's quite easy to do in the newest versions of ADT (version 17), though I do find it makes compilation a bit longer:
Create a new Android project (proj-A)
Go to Project->Properties, select Android, and check "Is Library"
Move all your common code to proj-A, import all the necessary libraries
Create a new Android project for Google Play (proj-B)
Go to Project->Properties, select Android, and add Proj-A to the Library
Repeat #4&5 for the Amazon version
If you have some variables that should be set differently for each sub project (i.e. boolean GOOGLE_PLAY_VERSION to enable Google Play specific functions), you have to create another project to contain these values since you can't have projects that reference one-another in a circular fashion. You can solve this by adding the following steps:
Pull all of your sub-project specific variables into one or more Classes that just serves as container(s) for these variables
Create a "dummy" Java project (dummy)
Config proj-A to add a new Source link to the bin directory of dummy
Add the config Classes in each sub-project with project-specific changes
Profits!
Note that the variables in dummy should not be set as final, otherwise it will override sub-project's setting.
This may seem like quite a bit of up-front work, but has worked quite well for me as far as version control goes.
Edit:
Now with Google's move to Android Studio & Gradle, it may be better to move to that if you are starting a new project if you want to support multiple APKs, see Android dev site's Building Your Project with Gradle#Work with build variants. It definitely doesn't hurt to evaluate that option before deciding.
Unfortunately, it's sort of a convention in Android to change flow at runtime based on what would be in C/C++-land conditional compilation.
Our app has to maintain different behavior for different API levels, so we've created some application-level constants that are initialized statically based on API-level information available to us, and used throughout the code. This is the way that Google does things in their examples (for example, see the ActionBarCompat compatibility library, and in particular the factory method used here).
You could create an interface CustomBuild, and implement it in AmazonBuild and GooglePlayBuild, then use a static getBuild() method to switch functionality as necessary:
if(getBuild().shouldEnableFeatureX()){
doStuff();
} else {
doDifferentStuff();
}
Then all you've got to worry about switching between builds is a line or two of code in the factory along with maintaining which things you want enabled in which versions. Or you could include a different version of a static class CustomBuild for each build.
I'm going to second the suggestion of others above re: switching to something like Maven for building; it should make your life much easier once you have it set up.
I'm also going to say you should make the core of the app a library as suggested above, and have two different modules (one for amazon, one for play store) that depend on the library but each only contain the one custom factory file (or just a static class for each type of build that contains the same "should I do this thing?" methods... once you have the infrastructure it's just a matter of preference).
I haven't actually tried this yet, but it's something I've thought about.
How about using Eclipse's ability to link to files from a directory outside your workspace?
Start with one Eclipse project: for the sake of argument, say it's the Google Play version.
Now build a second project, beginning with asking Eclipse to link (not copy) the source files from your first project.
To develop the second project, add classes that subclass ones from the original project to realize your modifications. For resources, you can use some combination of includes, attribute overrides, and selectors.
Where it's not possible to subclass or extend, then obviously you'll have to just copy the original source file and hack on it. If you're really OCD about it, you can probably just maintain a patch set rather than a whole redundant set of files.
What do you think, will it work?
You may create manually two projects in Eclipse pointing to the same source folders but with different inclusion/exclusion filters and different target directories.
Then two Ant targets using properties to switch excluded files from javac fileset are enough to generate corresponding jar files.
The aim is to get a clean application for each target, without any code from the other one.
With features listed as pluggable behaviors in a property file or XML configuration, your runtime will adapt itself with the addition of menu entries.
I'm producing an application for multiple clients. Each of these apps only slightly differs (in the ui presentation) from the others and almost all of the other code is identical.
In the best case scenario I would brand something like a boot-strap app for each client so they could have their logo on a separate app in the market. Once a user installed a client's app it would download the core functionality, set some prefs and launch as if it had come from a single download. This way I could get the benefit of updating for bug fixes once rather than for each application (slated for 20-30 by end of year.) I've read that this isn't possible because of security measures though (and additional visits to the market place for the second download or having to allow installation from unknown sources isn't acceptable.)
I'm thinking that worst-case/only-case might be to include this shared code in each application and create some batch build and deploy once updates are ready.
I'm looking for a .dll like approach for economy of effort and safety.
I'd appreciate any input on this.
Thanks!
The java equivalent of a dll is a jar file. You can extract all of your shared functionality into a library project that compiles into a jar and then include that as a library in your other projects.