Title says all.
Can i use mysql/oracle database in Android application even if it's very slow and bad ?
Remotely by using a webservice yes.
Locally , it's theorically possible but you probably have to :
have a rooted phone
recompile the source code of your DBMS to support the arm architecture (or whatever your phone use)
find/create a driver for java (supported by dalvik) which support this DBMS
find/create an api for this DBMS
Long story short , you don't want to do that ! It's cleary not a good solution.
And to be honest using DBMS like oracle on a phone , it is like using a rocket launcher to kill a fly ...
Note : you can have a look on this documentation about berkley DB on android
As far as i understand you need local database running on Android. That means MySQL/Oracle are not choice.
As there is only java - you can try to use java based DB. There are few on internet. Of course they have to be ported.
Yes, you can.
You just have to create .php that gonna get informations from the databases and return you a json.
In Android you create a httprequest in wich you target the .php file and analyze the json.
Related
I'm working on a project on mobile RDF databases for Android. Therefore I'm looking for open source databases to include in my Android project. However, it's difficult for me to find mobile versions of existing RDF databases.
What I've found so far:
Jena TDB database
Oracle Berkeley database
Unfortunately I haven't found mobile versions of Sesame, Virtuoso, AllegroGraph, etc.
Does anyone know some other RDF databases for Android?
I'm not an Android developer, so perhaps I'm overlooking something, but Sesame comes as a collection of maven modules, each a separate Java jar file. You can pick and choose the jar files you need and as far as I'm aware, you should be able to use them on Android straightaway. I don't think there's any need for a separate "mobile version", is there?
I am taking a look to Triple Place.
a light weight and flexible Triple Store for Android. It uses a
indexing structure similar to the one in Hexastore. TriplePlace uses
TokyoCabinet as persistent storage system.
You can find a brief presentation of its features here.
You can use SQLite to store RDF data and make queries for the triples, but SPARQL couldn't be done. Here is a good reference:
http://infolab.stanford.edu/~melnik/rdf/db.html
I would also take a look at 4store.
I have some configuration I want to save it in my Android application and read it whenever I need , for instance, the server URL that it should try to access like that.
Is there any similar mechanism like web.config in ASP.NET available in Android?
A central configuration file that can be set up manually and then read by the application? Any help would be appreciated!
We use a .properties file in assets folder. It works out very well for us as we support multiple carriers with this, write to it (in case some values, sent from server, need to change. This is done at app start time, thus making our code configurable from server).
You can throw things like that into your strings.xml file. But, since you can't actually modify these values in real-time (since it's a distributed application rather than running on a server), throwing it into a constants class is quite acceptable.
Use Shared Preferences.
Here's a link Shared Preferences
You can use sq lite database files for it. You have a native API to read and write those and on top of that a command line tool.
If you want to create an XML file instead, then it's no different than any other xml file (unless you are thinking about the Shared Preferences, which use an xml format to save the data, but I believe it's not the best API for your application).
I was stumped on this too, but came across Managed Configurations in the Android documentation.
Managed configurations, previously known as application restrictions, allow the enterprise administrator to remotely specify settings for apps. This capability is particularly useful for enterprise-approved apps deployed to a managed profile.
It allows you to set a default value in case you rather not getting into the enterprise admistration business but leaves that option open for the future.
There is a caveat. This only works if your app is registered for EMM. Otherwise you will retrieve an empty map of restrictions.
I am doing a forensic course and as a requirement I have been asked to develop a forensic investigation tool (windows based) for Google's Android OS. The requirement is such that given an image file, the tool should be able to display the databases that the applications are using, call history, messages and etc..
I have little experience in Java but I have no experience in Android development. The research so far has given me nothing on how to go about this. If anyone could point me in the right direction I would much appreciate it.
Thanks in advance.
Step 1 would be mounting the filesystem. Since Android is Linux based, there's a huge array of filesystems available, and individual vendors may or may not decide to write their own filesystems, just for the fun of it. On Windows, your options include ext2fsd or ext2read, among other possibilities.
Once you've got the filesystem mounted, then you get to deal with the per-application data storage. I'd wager a fair amount of applications use SQLite3, because it is an amazing tool. But you'll have to figure out, for each type of data you want to read, where it is stored and in what format. (The standard file(1) tool on Linux systems can come in handy, it knows heuristics that are surprisingly good at showing what type of file you might be dealing with.)
If you have the .apk of an application, a tool such as dex2jar, used in combinaison with something like jd-gui, can get you the JAVA source-code of the application (which can help, if not obfuscated).
After that, an .apk is basically a zip-file -- which means opening it with an unzip-ing application will allow you to get the images and resources it uses.
Then, databases used by Android applications tend to be SQLite, on which you can do SQL queries, using an SQLite client.
I have an Android app that has been already developed using SQLite.
The DB is quite large (over 100 Megs) so it can be deployed only on the SD card.
The data inside the DB is sensitive so for this reason we need to encrypt the DB.
The default SQLite binary on the phone does not allow encryption or to add a plug in (extensions).
I manage to compile the SQLite using NDK with the encryption extension (I am calling this SQLiteS - from secure) but I still need to figure out how to copy the Sqlite API and bind it to the new SQLiteS binary.
The idea is to not change the already developed code using the SQLite default API excepting the package name.
Any idea of how can I accomplish this ?
Tryp getting a native jdbcsqlite driver onto Android.
which makes sqlite3_* calls(JNI).
Use the aapt tool to link the library(sqliteS) into the .apk file.
Also, you can change the sqlite3_* names(in SQLiteS.so you built) so that it doesnt refer to sqlite.so file provided by android.
Let me know the solution.
I know this is not an answer for your question, but you could try the (free, open source) H2 database. It supports data file encryption as well. There are some disadvantages however, for example some operations are quite a bit slower. You would need to use the JDBC API because the SQLite / Android database API is not yet supported. Disclaimer: I'm one of the H2 committers.
Use sqlCipher. SQLCipher is an open source extension to SQLite that provides transparent 256-bit AES encryption of database files.
See http://sqlcipher.net/
There are some things my application needs to do on first start up(first startup after update) . These actions could be described in a .txt file and then when it is the case read the file and do according to it ,or on the other hand (I lean to use this option) a sqlite database could be used to store the information . The apk file would be shipped with an .txt file/prebuild sql db stored in res/raw or res.asset and then copied into proper space and used. This I have figured out how !, though I'm not sure which option of this two would be the fittest ? One thing that is unclear to me is how could sqlite version mismatch affect me, and if it serious enough to take into consideration ? I 'm using Android api level 4 (Android 1.6) and the future application might be used on several different devices , with different api levels.
These actions could be described in a
.txt file and then when it is the case
read the file and do according to it
,or on the other hand (I lean to use
this option) a sqlite database could
be used to store the information .
Or, they could be implemented in Java.
Well the actions that the application
needs to perform on install / after
update , according to the update
version and the pre update version of
the application
Why not just implement this as regular Java code in your app?
Or, as Albert Einstein wrote, in homage to Occam's Razor: "Make everything as simple as possible, but not simpler."