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 .
Related
I am planning to develop a Flutter App which will be installed on a dedicated device which I want to sell to customers (B2C). This device will be used only with the developed app and thus represents a kind of customized end user device, which hasn't to provide any other functions. For example, the user should see a customized boot screen and then my app should open. The user should not be able to access the Android system apps (Config, System Bars, Home Screen, Home Button/Navigation).
In doing so, I have the following problems:
What options do I have to update the app automatically?
I have read that there should be something like the Managed Google Play Store, but would this even be the right use case for this or should I rather write my own service which is responsible for updating my app?
How can I make sure that the user only uses my app and not other apps or the system menu? The following link (https://developer.android.com/work/dpc/dedicated-devices) describes how I put certain apps into "Lock Task Mode", but that is mentioned more in the context of Enterprise Mobility Management, not for customized consumer devices. Is this even the right way to go for my requirement, or should I rather look into the AOSP project (https://source.android.com/)? That would certainly add an additional hurdle. My preference would be to be able to use any Android tablet for my App.
In order to sell my dedicated device, I will need to customize/install a variety of devices, which begs the question of how do I effectively solve this? Do I need to flash the devices to do this? Is there possibly another effective method such as customized installation scripts via adb? This question is certainly closely related to the previous question.
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.
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.
Currently I am developing an android application. This application should load when the device boot and it should restrict all the inbuilt & other applications. I have searched in forums as it can be possible by make our ROM customized. But this process can be do manually by ourselves. I want to make this by coding. Or is there any other way to make my application default?
If you want your app to be default - yes, you haven only way to build your own custom android.
Only what you can do on your default android system is to automatically load your app after OS have loaded.
You're not stating precisely what you intend to do. The words restrict and default can mean a lot of things.
Despite what dilix writes, one way you might succeed with what you want is if you make your app a launcher. A launcher plays an interesting role in the system.
However, you cannot force anyone to really use it. But that wouldn't be possible either way, right? Unless you talk to device manufacturers.
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.