As the title says, I need to create a simulated Android environment within my app. I need to be able to install applications on this environment without installing them on the device.
I know it's possible because this app does it.
I've been searching for a while and I know the app does it by creating an Android environment, but I don't seem to find a lead on how to do it.
EDIT:
I found another app that can do it
Parallel Space
It depends to what degree you need to run the app and what constitutes "installing" the app. Keep in mind that an .apk file is just a java .jar file with some extra data tucked away in various places.
In order to run portions of an Android application without installing it, you will need to
Open and parse the apk. This APKParser class might be a good place to start.
Request any permissions which the app in question requires which aren't already requested by your app. In older versions of Android you would just have to request all possible permissions to start with, but with newer versions you can requestPermissions to make the actual permission request dialog when convenient.
Copy the classes.dex from the application into your data folder. If it uses any common classes which you also use, you'll probably want to nuke these out of the dex file so that you don't have class loading conflict, or else be very, very careful with class loaders.
Load the dex file with a DexFileLoader.
At this point you can load just about any code in the apk, but you won't be able to do a straight load of the Activities, since they're not defined in your AndroidManifest.xml. Instead, you'll need to create a "facade" Activity that hosts the actual activity in reflection and wires up things like the context into the reflected Activity.
These steps should probably work to run at least simple apps without installing them.
Build one yourself!
Android is built on Kernal, so does a Linux
Here is a link to a working project on github which works fantastic in a Linux environment
Here is the documentation on how it is built!
Related
An Android application that I am interested in (OpenSudoku) has become unmaintained by the original author, who last updated the application just under a year ago, in addition they have rejects offers of help from others to contribute directly to the hosted SVN repository.
I am interested enough in the project to seriously consider forking it (I am already familar with many arguments for and against forking in general), but I do have a couple of questions related to best practice with forking Android applications, specifically:
I understand that I will have to change the package name/namespace, is there an easy method I can use to do this (without breaking the Eclipse project files and associated references)?
Is there a way to help users that may want to migrate to the new application, recover settings/data from the original application? (My understanding is that the permissions model that Android enforces would make this impossible)?
Are there any other issues that I should be aware of that comes with forking an Android application that I would need to plan for?
AndroidManifest.xml, various build system files, layouts that use your own views, each Java source file, and the directory tree. That's what you have to change. I use vim -p glob glob glob for changes like this, and mv, which is easy enough.
Not unless the old application cooperates, which it likely doesn't. Perhaps your fork could detect an OpenSudoku install and prompt the user to install, off-market, an 'update' for it that just repackages its preferences for your consumption. I don't know if that works, updating a Market app with a non-market APK. Although, you said "settings/data". If 'data' includes e.g. sets of puzzles on the sdcard, yes, you can load that kind of data without any trouble -- FAT32 offers no security.
So... I'm trying to create a plugin for one of my apps. This plugin would require several views, images, an activity and a parser for CharSequences... Ideally, this plugin would be downloadable from the Android Market.
I understand how to create a library, but that would need to be included in the application.
I understand how to create an app as a service and just call it via intents, but I need direct access to objects and code that is neither parceable nor serializable.
What I have been looking at is eyes-free TTS. With their implementation, the developer includes a small TTS_library_stub.jar file in their app, which looks like it defines a lot of the necessary classes/objects.
So my question is, how would I go about building something like this and generating this "stub" .jar file, which would be included in my app? I've been trying to work my way through the TTS code, but it's a massive codebase, and I'm having trouble finding what I'm looking for.
Any help would be massively appreciated :)
The service and the app need to have the same sharedUserId in the manifest and be signed with the same key. Then the app and service can share eachothers assests, classloader and even run on the same thread. I have never included part of the GUI in a service, so maybe that is a limitation...not sure.
If there is a limitation, you must be able to work around it. Look at OpenIntents. It is open source, it is a service and you can download that from the Market. It provides a GUI file browser to any app that uses its intents.
Didn't full understand what you needed, but thought this might help.
If you want android library to be downloaded from market, It has to be standalone android application. (not android library project!). Then you can upload it to market, download it to phone and communicate with it via intent(which this library can handle) or service(aidl) or provider(the data from library) and perhaps receiver, but I never used it in that way.
If you would design your app for an OSGi environment like apache felix it might be possible to load libraries at runtime.
In their presentation they described how the whole concept is working.
Since only APKs can be shared in the android market you would need to write your own "update mechanism" which downloads your OSGi bundles (your plugins) and deploys them to felix.
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.
I need to build two version of same android app and install both on same device, i can achieve this by keeping two different projects (different package name),but it's pain full to manage both, rather than keeping two projects is there any better way to achieve this.
Sam.
You can use a library, but you'll need to restructure your code quite a bit in order to do it.
Basically, write the code specific for one app in one project, and the code specific for another app in another project then write the code thats the same across both apps in a library and reference it.
Can I ask what your doing this for though? If your doing a "free" version of your app and a "paid" version there are a few other options as well. Like making a dummy app and checking for it's presence in the main app.
If I needed to build an android SDK that other developers can integrate into their android apps, is jarring my SDK the only way to go about it? As far as I have learnt, jarring has the following considerations:
If your app uses a layout, then you have to create it programmatically. Since jar files cant carry any resources.
The jar will needs to be placed in the lib/assets folder and added to the build path (in Eclipse) -- Learnt here: Android - Invoke activity from within jar
The main app will have to create an Intent object and specify the package and class name in the jar to start the activity.
Any one have other ideas of going about any of the above steps?
Thanks
George
Creating a JAR is, in my opinion, a very bad decision. Android has specific features just for the kind of thing you're looking for. If your JAR:
provides some sort of (structured) data to be used in other applications, use a ContentProvider;
does some backround processing and makes that processing's results available to other applications, use a Service;
provides an Activity that gets some input from the user (or shows some information about something), eventually processes it and returns it to the calling Activity, just create that Activity and any application will be able to start your Activity as long as it's installed on the phone.
If you use one of the three solutions above, third party apps will be able to probe for whether your application is installed and, if not, prompt the user to install it. Only if your application does not fall into one of the three bullet points mentioned above should you use a JAR. Otherwise, using a ContentProvider, Service or Activity provides:
More standardized interaction between components
Better maintainability -- if you update your SDK you won't have to call everyone who uses it and tell them to upgrade.
No duplication -- if you were to provide a JAR and multiple applications that use it would be installed on a device, multiple copies of the JAR would be present on that device, thus using more memory than it has to. If you provide one of the three components mentioned above, one copy will satisfy all applications that need to use it.
Again, these components are specifically designed and provided by the Android OS for creating such SDKs. Please, only use a JAR if you really, really have to. Otherwise, provide a standardized ContentProvider, Service or Activity and document the way it's supposed to be used (i.e. how to use/query/integrate it).