One of my friends suggested to use c++ support in Android studio in order to hide passwords. I have found tons of tutorials how to get started with ndk in android. But they are all outdated(2015) and everytime I try to use c++ in any way, Android studio crashes. Is there any way to do it in a simpler way now?
P.S./ I want to get rid of experimental plugin that every one uses.
Little off the question, storing passwords in the native layer does not ensure complete safety. A good hacker can get that as well. It is just that you add another additional layer so one has to dig deeper
Related
In my recently started internship (I'm studying computer science), I have to port a somewhat big existing Project to Android. It is a Visual C/C++ Project which in the end should run on Android using of course the NDK. The problem is that I don't know a thing about porting software, since this is not covered in my studies...
I had a few days to get to know the project I will be working with a little.
A few words about the complexity:
It is a Visual Studio solution which consists of 28 projects of which most are kind of big...
And now I need to develop a concept for porting it to Android, and this is why I'm writing this. I have absolutely no idea know where to start, also I don't know how to get to a concept for porting it. I tried searching online for some stuff or for some books covering this, but I found nothing.
Of course I know, that basically I have to remove everything that is Visual/Windows specific and replace it with appropriate Android/Linux functions or implement something new if there is nothing corresponding on Android.
But since this project is somewhat huge, I can't just try to compile it with the correct compiler and work through the error messages, this will lead to nowhere, I guess...
So now my actual question:
Is anybody experienced about this or something similar and can give some tips how to start with it? As I said, I first need a concept. Something more general about how to start and deal with porting a software project of this size is also very welcome, since I don't know nothing about it...
I think that you're approaching the whole matter in the wrong way. There are several tools that will allow you to compile C# and visual C++ and other visual languages from their respected IDEs to the android platform. For example there is mono for android . Mono is a plugin for visual studio which helps you create android projects using visual studio and .net technologies. I think you should focus your research on tools like this because changing all of the code manually is nearly impossible and too time consuming. Here is a page that will help you get started with mono for android. Good luck.
See this answer Android NDK with Visual Studio.
Personally I don't use this, but It seems to be a nice solution to your problem.
Like you, in the past, we had to port a big Visual C++ library project to Android, we proceeded in this way:
Try to compile the main library interface (by creating the relative Android.mk)
By using linking errors, you should guess other projects to be compiled and create the mks for them
Cycle until you have no more linking errors.
You didn't tell about the source code size of the project (how many thousands of lines of source code).
If the code size is big enough (e.g. at least 100 KLOC), you could consider customizing the GCC compiler (assuming a recent 4.6 or 4.7 version), perhaps using MELT (a high level domain specific language to extend GCC), or painfully coding in C a GCC plugin. This GCC customizing approach is worthwhile only for large code bases (you'll need several days to master GCC internals).
On the other hand, many well designed applications may have packaged their operating system functions inside a well defined interface and library. You might consider porting your application to Qt or some other cross-platform library.
We need more details about your project to help you more.
Is there a handy-dandy equivalent to org.apache.commons.beanutils.PropertyUtils on Android?
I can't seem to use bean utils in my android app due to some dependencies on PropertyDescriptor,and IndexedPropertyDescriptor. So I'm wondering if there are any alternatives?
Basically all I want to do is use a method name as a string "someMethod" and feed that into setMethod(anObject, "someMethod", value), much like PropertyUtils does; but without having to resort to the nasties of reflection...
Or are my hands tied and I need to use Reflection?
There is bridge library which works on Android: android-java-air-bridge.jar. Just include into project path and use all apache beanutils features in your Android project as you could use in ordinary java application. Moreover, there are lot of other classes which moved to this Android supporting library. Look at the list.
There is a possibilty to use libraries or write own code depending on the PropertyUtils. But it sure isn't dandy. You can get the general idea about what has to be done in this thread.
There are apparently some projects who have successfully solved the issue, so you can study thier solution. Take a look at Drawingpad-base and libgdx. You can find PropertyUtils in the package com.madrobot.beans in the first project and com.badlogic.gdx.beans in the second.
I know there is a dedicated area for Android issues, BUT I just want to know if there's an option to program to Android in C or in Java, and what will be the best language to write apps for Android.
This info you can't find in the Android area...
Thanks !!
Android practically is java.
Just read some how to start tutorials and you will see theres not much difference to conventional java applications.
It is Java with some platform dependent features.
SDK:
http://developer.android.com/sdk/index.html
DevGuides:
http://developer.android.com/guide/index.html
The Android API is in Java. You can find the developer guide here.
For performance-critical code, you can use the Android NDK.
Android's comprehensive java SDK makes it a lot easier to write apps in Java. You should check out the getting started page on their developer site.
The best? Java.
You can also write in C/C++ with the NDK.
And you can also write with Python or, say, Scala, but is not easy at all.
Java is the best because the API is Java, so all the documentation is in Java. Equally important, Google's ADT plugin to program Android in Eclipse is super easy, so you are going to work with an IDE, no need to advanced text editors and so.
Android applications are java based. (although I heard new NDK support development of full application in C).
It is possible to develop some libraries in c/c++ and load them to your application using JNI, which is also a Java feature. Start from here: http://developer.android.com/index.html I know it seems to general, but the official site is a great place to start from.
You use Java to program Android. It says it in the documentation for development for Android.
You can also use the NDK but don't start with that.
I am a beginner on android platform, and I want to build a tracerouting app. So these are my queries:
Is it possible to make such an application in Android? if possible then guide me the way that I follow.
Does Android support low-level programming to capture ICMP packets? or do I need to add some kind of JAR (in java) or some other libraries to support this application?
In Java, there are JPCAP and docjar etc kind of libraries that we can import in our IDE or Eclipse so that Java support for making such kind of API's?
I need valuable suggestions.
It's quite late - but someone might see it.
i found this one and it worked for me:
https://github.com/olivierg13/TraceroutePing
The simplest way I can think of is to just check for the traceroute Linux application, execute it, and parse its output.
Android has full networking support, however, Java doesn't expose an interface to alter the IP header. Hence, manually crafting ICMP packages is out of the question (JPCAP is no help here, since it relies on libpcap, which I suppose you won't find on any vanilla installation).
Another possible solution is to use the NDK and create a small library that handles the low-level number crunching. However, I'm not sure if the NDK would allow you to use setsockopt.
This is working pretty well for me, you may have to filter out the string results.
To add this library, you have to download or clone the git repository and implement the folder "library" just as he does in the other module "app" for it to work properly.
I was wondering if someone could provide me with a bit of theory. I read that;
Page alignment causes changes in
linking. Of very high impact on the
success of compiling software for
Android is the fact that Google forces
compatible binaries to not be page
aligned for the text and data section.
This requires changes in the way of
linking object files. For self-written
software, one can take precautions and
react on this fact with compiling all
shared libraries accordingly. For
already existing source code, changing
the linker’s behavior can present a
very tiring and, often, an even
impossible task.
But personally know very little of page alignment, what does this actually mean? Is this the reason we must change the asx file when compiling native libraries for use on Android? Here's the context for that statement.
Apologies if you think I should just Google this, I did try but I'm just looking for a bit more of an explanation than there is at that link.
Kind regards,
Gavin
using CodeSourcery and a linker script is not a valid way to create a native library on Android anymore.
Take a look at the native library example at development/samples/PlatformLibrary/ to see how you should build a native library.
For the start, you can modify the PlatformLibrary example to make your own library. Compiling the code should create the following files:
out/target/product/generic/system/app/PlatformLibraryClient.apk
out/target/product/generic/system/etc/permissions/com.example.android.platform_library.xml
out/target/product/generic/system/framework/com.example.android.platform_library.jar
out/target/product/generic/system/lib/libplatform_library_jni.so
You do not have to worry about those linker issues anymore.
Regards,
Manny