Hi I have been tasked with investigating the feasibility of developing an anti-malware app for Android. I am led to believe that Android apps run in their own 'sandbox' and have no permissions to scan outside that sandbox.
How is it then, that apps (eg. antivirus) already exist that must be able to test files in other apps' areas? I don't imagine an antivirus program would be very effective if it could not test files phone-wide. How would this be done?
Thanks for any advice!
It is true that an app is run in their own 'sandbox' but it doesn't mean it is confined to not access outside the sandbox. I'm assuming by sandbox you mean the apps virtual machine or something of that sort.
For instance you can exchange information and talk back and forth between 2 apps using Intents, which lets you grab information from one app into the other. Again there are 2 ways of looking into it, this can be considered as a feature which lets you access outside stuff or as a security vulnerability. Which leads back to glass half-full or half-empty scenario.
I'm not sure if I understand your dilemma correctly. But hope this helps.
Related
Is it possible for one Android application to modify the settings of another application?
Say, I want to create an app that temporarily blocks notification from all other apps. Is it even possible?
I can see from the official documentations that all apps run in their own sandbox. But I wanted to know if there are any workarounds for this.
The other use case I had in mind was to create an app which could migrate all the apps from phone memory to SD card memory.
Both of them require tweaking settings of other apps.
The only way you can touch another app's setting, is using root.
Unless the destination app gave you the option to do so, using intent maybe or an API.
It is not possible as you said in question , each app runs in their own sandbox . If it is possible , people would have hacked all apps .
For a POS system is there a way or ways to make an application harder to close?
The desire is to have employees be able to use the device and the application, but not use other applications.
The implementation does not necessarily require a password. So far the answers I have seen on similar questions suggest this is not possible. Except in Lollipop per this question : How to make an app unclosable?
Are there any options for older APIs?
Or am I just out of luck?
That is not possible as a feature of the API since the Android system is in control of what is executed or stopped. And that could mean that your app gets stopped for a number of reasons.
To achieve what you are asking for you will need to create your own distribution of the system. I have no experience of doing that but it basically means creating a rom and distribute it.
That would of course be an option if the device running the POS app is only used for that particular task.
I need some guide and help from you guys, What i want is as follows:
Replace the device home screen with a customizable screen that limits users to selected applications only. This should allow the administrator to select the applications from available list of applications.
Specify a URL for device redirection (in case of browsing)
Create a whitelist of acceptable URLs (no other URLs will be accepted)
Enable/Disable native Samsung Android device following features.
Android Market (App Store)
Camera
WiFi
Bluetooth
Microphone
Access Point
Now can anybody guide me what to do and where to start in android?
Your help will be really appreciable.
Thanks
As mentioned by Evan, this is really the domain of Mobile Device Management (MDM) and involves a pretty heavy-handed control from the app.
There are a number of solutions already available such as Air-Watch or Good who specialize in exactly this sort of thing.
I think building your own from scratch would certainly not be trivial, though there is a lot of discussion which could help in getting you started (check here for instance).
Good luck!
To archive that, I think you must build your own Android ROM. If you only want to install your HOME app to a device, user can easily get back old home screen.
I need a device that runs only one custom application and does not allow the Users to access any other features. Building a complete device would involve a lot of time and money for sure(only if this can be done with android). This can usually done for each android device seperately. It could be better if there could be simply a piece of code that can be simply executed on the device that installs the application and at the same time restricts the device as per requirement.
Could someone advice me a way to implement in the Android devices. Is it something possible :(
Would also like to know if the same is possible with iOS..
Thanks..
If you want to be absolutely sure that users cannot do anything but accessing one specific app, the only way to do this is to create a custom ROM that allows to install your app only.
I am writing an Android application that uses some functionality that has been published under the Apache 2.0 license. The functionality is available in 2 ways:
As java code
As an intent in an Android application.
Being the typical developer that I am, I don't want to make the user install a separate application so that they can use my own application - because it would definitely put me off using the application if I had to.
On the other hand, doing the work to get the application up and running using the Java code will take much longer.
My questions are thus:
What are most developers doing now? Are they using intents from other apps?
Does it matter to the average consumer that they need to download a separate application to make it work?
In my application EmailAlbum, I first depended on the presence of OpenIntents OIFileManager on the user phone to pick a file on SDCard or chose a destination folder for exporting a generated file.
Later, I integrated my own version of the code of OIFileManager in my app's source code for several reasons:
Depending on another app for basic (but essential) application features is like a suicide. If your app can't really live without the other app and this app is not installed on most devices, your app won't get used. Most people want apps that work on first start.
Another app was on the market which was providing it's own (bad) implementation of the same intent and was making my app crash... users having it installed on their phone thought that was my app's fault.
Providing a consistent UI was not possible.
I think using public Intents is great to allow people to chose from various applications to extend your applications features or to reuse the content generated by your application. BUT your application has to be able to live on its own, depending only on standard apps provided with ALL android devices (ie. not even depending on Google proprietary apps if you want your app to be able to be used on devices which have not been approved by Google, those which come without the Android Market or GMail).
Most developers are going to use a common intent (phone call, web browser, camera, etc.) to call an activity. If your app replaces one of these common intents, then you shouldn't have anything to worry about.
Developers do sometimes include intents to use other (non-common apps). One example that comes to my mind is OpenWatch that provides an API for other developers to build on. Of course, in this case, if you are using a bluetooth watch like this, then you most likely already have OpenWatch installed, therefore it isn't much of a bother to get another app that builds on top of it.
If you think people are going to use it, I'd say provide an API.
Might also want to take a look at here: http://www.openintents.org/en/
I think even google had an app at one time that depended on a third party package. At application startup the user was greeted with a dialogue that asked him to download said package. If he declined, the respective functionality was disabled.
But I'd only use that approach for tech savvy users, the regular joe will much likely be put off by it. If the functionality isn't crucial, just use it as an added bonus and leave it out otherwise.