I'm developing an app for Android Tablet PC and I need to allow user to run only exact applications.
1. Is there any way to deny other applications execution?
2. Is it possible to show some block screen with password prompt and deny user to run anything until the authentication will be passed?
Unfortunately I haven't find any info :(
If you're talking applications (and not just activities within an application) then it would not be "safe" for google to allow you to block other programs from running. If you had your own (non-stock) version of Android that you were deploying on company devices for example, then perhaps you could do that, but if you're just making an app, it would not be wise to have an app prevent other ones from running. You could perhaps set up some kind of shared memory resource with some flags that other apps could look at upon launching to see if they should proceed or not, but that is about it.
You would have to write a replacement for the launcher & app drawer so that you can manage the application launch process. There is a demo for creating a launcher in the SDK, and a short thread about it here
Related
I am working on an Android application This application is a parental advisor application and it will be installed on the parents' phone and on the child's phone.
My question is how will the screenshot be taken from the boy's phone without his knowledge?
thats pretty high privilege, which need special permissions. you probably have to create AccessibilityService, but be aware, that Google Play may refuse your app from publish in their store. btw. you can't start this Service from the code, user must enable it in system Settings
I find this question a couple places on the web, but never with a good answer. Let me be specific in the questions asked.
I want to build a custom Android ROM which only features one app. This app is not to interact with any hardware (per now). This app will be launched on the start up of the device. No locked-screen. The device will have to restart if the app malfunctions.
A resource told me that you can change the launcher app of the ROM.
-> Does this mean that the home screen, the one which displays all apps on our phones, is merely another app? If so, can you simply change the launcher app as it is stated here? What were to happen if this app fails?
If this is the case, it would solve the entire issue.
If not, how do you go about making this sort of project? It includes
Making an app on AOSP
Refuse users to leave the app or interact with anything else
Making this app part of the boot-up process
Remove locked screen
Make the app a dependency of the OS (to force shutdown if malfunction)
Thanks in advance for any replies
I just found Android have a topic about dedicated devices (formerly called corporate-owned single-use, or COSU) are a subset of company-owned devices that serve a specific purpose. maybe that can meet your requirement.
BTW, After into the sub-topic lock task mode that mentions about set DPC whitelist APPs and the device policy controller (DPC) needs setup by other steps.... FYR~
I am interested in developing a custom Android launcher which would be installed onto a device primarily for censorship. Ideally a device would divert attempts to launch applications to a service which would decide, based on a profile, whether the user would be allowed to proceed, or be shown a block screen/redirected to an informational web page.
Is it possible to detect and interrupt application launches via some kind of background service or attachable listener? Or alternatively, might it be possible to have a launcher launch a different application than the one clicked on, in order to allow for indirection?
Or, if all of this is impossible, can a service running as part of a custom launcher dynamically hide/unhide launch icons based on triggering events/messages?
There is no way to catch an app being launched and redirect that. If you think about all the horrible things people could do with this it's easy to see why. I think you're going about this in the wrong way. Instead of trying to enforce these rules with a custom launcher you should look into one of the Mobile Device Management options that are available for Android or work on creating your own.
Recently my employer asked me to build an app which is to be deployed on the field (for field workers) having features such as:
-when the phone starts the app should automatically fire up and no one is able to make use of other phone's features such as calling, texting etc.
Also, the app should be as such that it cannot be uninstalled.
Imagine a complete restricted access to phone's features except my app; a total lock down situation?
So, how really can I go about this? Will I need to build a whole new custom ROM loaded with my app? Or will I have to make use of app's "permissions" to lock down the system? Which is better?
Where should I start?
My app has to make use of SQLite, GPS, Wifi/2G/3G network and camera access.
Any advice would be appreciated.
Thanks
U can create an application which will be listening for Activity starting event. When u catch this event u can start your own activity. This activity will suppliant uninstall activity. To catch event - use logcat reading
or
If your are going to launch your own android phone, put your application in the android source, like the other native applications like Myfiles, Gallery. and
modify the source, so that in Settings --> Manage Applications there
is no entry for your application.
First of all I should say such a horrible plan
you can not prevent system to uninstall your application. According to your client's requirement you can only do one thing. That is to launch the application when the phone is started by using BOOT_COMPLETED intent filter
I am designing an app for Android, iPhone/iPad and Windows Phone using GWT and PhoneGap. GWT will allow me to write the entire app in Java (my strong suit, unlike JavaScript or CSS) and will translate it into cross-browser JavaScript/AJAX. PhoneGap will then wrap that resultant JavaScript and turn it into a native app for each of the three platforms mentioned above.
I would like to have a "plugin-oriented architecture", whereby users can optionally purchase (or qualify for through other means) "add-ons" (plugins/extensions) that will enhance the functionality of the app.
Normally I would accomplish this by using the Java Simple Plugin Framework (JSPF) and allow users to download plugin JARs as they paid for them. These plugin JARs would then be added to the classpath of the main app so that the next time it starts and scans the classpath for plugins, it finds them and loads them.
Is this possible with native apps? I don't believe I can deploy anything other than APK, IPA and XAP (Android, iPhone and WinPhone respectively) files to these marketplaces.
In Java-land, this would be like having to download a "base" app in the form of an executable JAR (containing its own main method), and then having to download a "plugin" app that is also an exectuable JAR, and somehow get the two to behave like a normal plugin architecture (which would be if you have 1 exectuable JAR base app and then 1+ plugin non-executable JAR libs).
So I ask: how do add-ons work for native apps from a deployment/download perspective? How do you get 2 or more APKs/IPAs/XAPs to communicate with each other on the client-side? If not possible, how do native app developers handle add-ons (I know they exist, I've seen them!)? Thanks in advance!
as for iPhone - the only way is to implement the additional features and have them disabled until the user purchases in app to unlock the feature.
In Android you can have apps communicate with each other so that the user can just load add-on apps that provide only the add-on functionality. For more detail on this.. android communication between two applications
WP8 - I do not yet have experience
Although I am not a core Android Developer, here are some suggestions from my experience with Android till now:
One possible solution for Android is to use Updates for application. One way to achieve this is using a Background Service which checks for updates whenever app starts or use GCM (Google Cloud Messaging) to push update messages to the app. Second option is much better as you can provide instant update to the user ,on per device basis (a user can have multiple devices), as soon as he/she has bought your add on feature. After the user has got the update message you can download the whole app with new feature and update app on the device. Of course in this case you need to backup the existing data of the app and restore after installation of updated app.
I don't know if this thing can be done but it would be also be an good option in my opinion if you can provide a legitimate user, who have bought the particular add on, an updated app through Android Market.
Another way is to create each add on as a Service and then let the main app can detect (or bind) those services at startup and if they are available, your app can communicate with them easily. You can even call the UI portion of the newly deployed add on from your main app by using Intents and BroadcastReceivers.
You may also find this useful as far as Android is concerned:
However, there are ways for an application to share data with other
applications and for an application to access system services:
It's possible to arrange for two applications to share the same Linux
user ID, in which case they are able to access each other's files. To
conserve system resources, applications with the same user ID can also
arrange to run in the same Linux process and share the same VM (the
applications must also be signed with the same certificate).
Hope this gives some useful information to you.