Which is safer for Algorithm implementation? [closed] - android

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've a data processing algorithm which I will apply for one of my Android Application. The Algorithm can be implemented via Java or Native Code C. But which is safer for algorithm implementation Java or C as so far I know Android Dex file can be reversed engineered. Is it also applicable for C?

Code safety is maximum when you do it in C(native) than java.
"so far I know Android Dex file can be reversed engineered. Is it also
applicable for C?"
Doing it in JAVA
By making your code-pakages to library you can make your java codes safe. Even if its reverse engineerd or your apk is breaked your code will not be visible, It will be like encrypted format. Change you algorithm package to library and add to the project assets folder and buildpath.
Doing it in C
And if you are doing it in C its sure that one who breaks your apk cant see your C code. Sometime it will be visible but it will not be in readble format. If you are implementing it via C, it will make the process more faster than in java and also you will be allocated more memory to do the process. Heap memory will not be a limitation for you code. The only thing is, Because of using JNI chances of getting errors are more and it will be difficult to trackdown the errors in runtime.
NOTE :Since hacking can be done in many ways.. I cant give any compleate assurance..But in most of the ways this is the thing ..Making your algorithm packages to library and adding it to project with buildpath or doing it in native, you can make your code safe to maximum extend..

If you want your algorithm to be perfectly safe, keep it in your head.
If you want your algorithm to be relatively safe, keep it on your server.
Any code can be reverse-engineered. People have been reverse-engineering compiled C code for decades. Bytecodes for interpreters, like Java and Dalvik, tend to be easier to reverse-engineer, bringing it within the skill set of more people. However, that tends to be of greater concern where what's being protected is software licensing. If you are worried about "a data processing algorithm" outside of licensing, your average script kiddie isn't going to care about it, and a competitor who really wants to know what that algorithm is can figure it out if they have access to the code, whether you wrote it in Java, C, or hand-coded assembler.
Hence, if you do not want people to reverse-engineer your code, do not let them have the code. Keep the algorithm on your server.
If your response to that is "I do not want my app to have a dependency on a server", you are explicitly stating that your "data processing algorithm" is not important, at least compared to having that dependency. And at that point, you really have to start asking the question of how important the "data processing algorithm" is altogether.

Related

How to obfuscate a pre-built apk? [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 years ago.
Improve this question
I'm a blogger and I've been publishing third party android apps and games on my website since a couple of years ago. There are some exclusive apps which I need to put some toast messages in them. I'm novice at this but my question is about something different. I just want to obfuscate a prebuilt APK app or just a particular string in the activity. There are so many articles or tutorial videos in the web in which people trying to teach this method by ProGuard in Android Studio. But I couldn't even find a single tutorial which explains How to add a prebuilt APK (NOT A NEW PROJECT) in Android Studio and obfuscate it. I tried to profile/debug an APK with Android Studio but I can not find the gradle.build to set the minifyEnable to true. I know this might be so stupid to ask, but can anyone help me with this? I just need to obfuscate a string (mostly my toast messages) or the whole classes of a Pre-built APK. Is there an easier way to do this or I have to do it by Android Studio? I would really appreciate if someone tell me how to do it in the easiest way possible. And do not consider me as a programmer or developer.
If you have an unobfuscated .apk file in a folder and want to obfuscate that, then you're out of luck.
Obfuscation works on a much lower level, and is done while the .apk file is being built from the source code.
And Proguard will not do anything at all to obfuscate your strings. Even if the .apk was obfuscated using Proguard, all strings and resources would still be in the .apk file and could easily be read by anyone with a bit of technical know-how.
Proguard obfuscates the code itself, not the resources (resources would be strings, numbers, images, etc)
There are some other methods of obfuscation (DexGuard and Arxan for examples), but those are much much harder to use, even for an experienced developer.
And you mention you want to add a toast message into a prebuilt .apk file? That requires extremely (and i do mean extremely) high knowledge of how the .apk is built, to dissamble it and rebuild it.

How much do I need to know about compile time vs runtime to comfortably write code in general [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm a self taught programmer starting to browse info about the range of C languages and Object Oriented Principles for developing iPhone and Android apps. One thing I come across often is mentions of what this or that language does at compile time or run time. I know I'm going to end up in a deep rabbit hole of studying, but how much further do I have to go with learning about compile and runtime in order to guide my decisions when I finally start writing my first lines of code? Will it make writing code faster and easier if I take the time to study compilers and such?
C and C++ are statically typed programming languages, which in general need a compiler to produce the final runnable program. To run a program, you first need to compile it (at least in most typical implementations, although in theory one can come up with a C++ interpreter), then run the produced executable. This process takes some time, however you shouldn't be too concerned about it, especially at a beginning level. The issue becomes more serious when you have code that's spread across multiple compilation units, with tens of thousands on lines of code. So for the programs you'll write the compile time will be negligible.
Compile time becomes a bit more serious whenever you use a lot of template code, which needs to be instantiated for various types (which takes time at compilation), but again, for relatively small programs, this is a non-issue.
There is another more advanced topic called "template meta-programming", in which you can make the compiler perform "stuff" for you at compile time. In other words, the compiler performs (useful) computations during the process of code compilation. However, even if this topic is a cool one, and there are many gurus around here, you won't need it at first, and you can start learning it after you master the basic C++ techniques.
Studying how compilers work and such is fun, but it won't make your code run "faster". Using appropriate algorithms is what makes your code faster. Micro-optimizations come only after.

Why do iOS and Android force you to write the UI in the native App Programming language? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
:) When you write a iOS App, in order to use the UI like buttons. you have to write it in Objective-C. (Java on Android). I was wondering if anyone had any thoughts on the technical reasoning behind this. Why they might of done this. As you can write apps in C++ on iOS so I've never fully worked out why they didn't expose a way of making the UI in that. (Ignoring the fact that this is how they did it on the Mac).
Note: I know you can write apps in c++ for Android but the question is more why is the main UI i.e buttons etc forced to be written in a dynamic language for these platforms, why not expose access to it thorough C++ without having to write a crude wrapper or binding layer yourself.
I'm guessing that when the original framework engineers were working on their respective operating systems, cross-platform desires like UI support in a different language like C++ was at the bottom of their concerns. You'll have to realize that when deadlines loom, all of the features are prioritized only what is considered most important is made to work. Everything else is a consequence of that.
In the case of iOS, Objective-C is the language of choice for the OS that Apple uses. All of the MacOS app developers were writing in Objective-C so their developer based was in familiar territory.
In the case of Android, Java was already a popular language, with existing open source tooling and libraries (Eclipse IDE, Apache Harmony), so presumably they decided to use Java as the first class language for app development with apps running in a VM as a consequence. Alternatively the decision may have been VM first for the sandboxing of apps and Java was picked as the language for app developers. Or some other reason.
In either case any attempt to add in additional languages now that both are in the hands of customers means design decisions and trade offs along with a host of other questions like: how to add it in without breaking existing APIs, how to support it along with new features, how to test, etc. etc.
As you see more and more software, you'll realize that lots of stuff is just arbitrary or made sense at the moment of when it was designed.
iOS does expose a C API for drawing UI components; it's called Core Graphics.
Because the view itself is written in Objective-C, or Java, respectively. When in Rome, do as the Romans do.

Porting a C++ application with Lua scripts to android? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I'm looking into porting an application called ygopro (source code here) to Android. I was just wondering if anybody can help me out by telling me what would be the best way to go about doing this? I would prefer to not spend more than about 60 hours on it and I certainly don't have the time to go through and rebuild everything from scratch. The code is in C++ and there are about 5,500 Lua scripts to do various things. Is there any easy way I can port this?
First, you'll note that the graphics library used by this project is based on has been ported to android.
There are two demos available for that project. Those will show you how to write an android application that uses this library. I suggest you essentially hack your projects source into the framework they provide.
In terms of Lua, again you'll want to use an existing port. Many of the Lua ports are oriented towards allowing access to LUA from Java via JNI, but you just want a Lua shared library out of them to link to from your C++ code. You will probably want something like AndroLua rather than the Android Scripting Environment. Pretty much, add all the folders in it's jni folder to your Android.mk includes, add it as a library, and you'll be good to go.
In terms of actual porting, I'm assuming that the project currently compiles happily under GCC. If that is the case, as you try to build it, it will complain about functions that are platform specific, and you will have to replace these. That should be manageable, if you are slowly adding code to the graphics framework demo as suggested. Beyond that, some libc functions are missing, but generally only rarely used ones.
Hope this helps. It goes without saying that you should complete some Android Native tutorials before starting. This project is more than a weekend.

Moving to Android from J2ME [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Coming from J2ME programming are there any similarities that would make it easy to adapt to Android API. Or is Android API completely different from the J2ME way of programming mobile apps.
Actually the Android API is much more powerful than the J2ME.
It is much easier to create an application for the Android.
Using the J2ME you are limited to simple forms due to the absent of swing-like libraries (though now there exists a library called LWUIT, avoiding the need to recreate from scratch a swing-like library).
In Android you will be able to create complex form very quickly, and software package for the android SDK is easy to install (while in J2ME you have to install the wireless development toolkit from sun, or install one of Nokia's, Samsung's or SonyEricsson's... it gets a bit confusing sometimes).
The things I had to change when switching from j2me to android were:
1/ The font and graphics class is easier to use on j2me. The API is more thorough on Android, but also more complicated.
2/ If you are used to the database storage of j2me (RecordStore), well you can forget it in Android. You will have to use a SQL-like databased, so be prepared to rethink your data model.
I've also found the path from Java ME to Android to be pretty simple. Here are a few things I've noticed:
There is ONE ui draw thread in Android. You have to be aware of the difference between calling postInvalidate and invalidate on Views to force them to update.
The actual bit-wise graphic manipulation is very similar. I was able to port large amounts of custom J2ME draw code by writing a few shims for drawRect and drawImage.
Android's UI library is much more extensive, much less useless, and much more complicated than Java ME's
Threadwise, you have to be much more careful about thread saftey with Android. In Java ME you can get away with not making methods synchronous or variables volatile most of the time. Not so in Android.
I will say, on the whole, that Android's UI library fails a critical test. I call this the "roll my own" test.
Your UI library fails this test if it takes me longer to complete a detailed task task (say, changing the background on one individual menu item) than it would take me two write my own Menu from scratch. Android fails the "roll your own" test by a factor of 3 or 4. In fact, if you look, the majority of the questions on this website are "How do I make the Android UI toolkit do my bidding?" questions.
Android is an amazing platform and it has been worth every frustrating moment I've sunk into it. It is, however, a young platform, and needs some serious work in times to come.
A good start would be to watch the Android architecture videos and look at some of the documentation.
http://www.youtube.com/view_play_list?p=586D322B5E2764CF
http://code.google.com/android/what-is-android.html
Google is very good about documenting. From what I've heard Android very very similar to J2ME in its goals. It may be slightly different in programming style and structure but if you have J2ME experience you should be more then ready to move on to Android.
Good Luck!!!
Well, you may not actually need to adapt.
There is a good chance that a J2ME stack will become available for Android before long since Android is not supposed to become as restrictive of third-party runtimes as the iPhone.
I know one guy who has been working on just that:
http://justanapplication.wordpress.com/
Now, of course, that doesn't mean you shouldn't have a look at the Android APIs and application lifecycle.

Categories

Resources