AFAIK there is absolutely no way to detect the moment when app gets uninstalled.
I am currently writing an app which should among else toggle on/off 3G data. It went ok before 2.3 with ITelephony reflection calls, but from Android 2.3 this is not possible.
So I had to resort to APNDroid-style way of adding suffixes to APNs in content://telephony/carriers. This seems to work, but I stumble on the same problem as APNDroid has: since we can't detect when the app is removed, all the suffixes will remain if the user first turns off 3G with the app and then uninstalls the app.
This is an ugly and dangerous solution, because the end user may be left with all APNs broken.
It's possible to detect uninstallation from another application, but how would one force the user to install another application to just monitor the first one? It seems there is no way from 2.3 on to write a 3G-managing app.
Any ideas?
AFAIK there is absolutely no way to detect the moment when app gets uninstalled.
Correct.
I am currently writing an app which should among else toggle on/off 3G data. It went ok before 2.3 with ITelephony reflection calls, but from Android 2.3 this is not possible.
Which means that you should not be implementing the app as an SDK application. You should have not implemented the app using "ITelephony reflection calls", either.
This is an ugly and dangerous solution, because the end user may be left with all APNs broken.
Which means that you should not be implementing the app as an SDK application.
how would one force the user to install another application to just monitor the first one?
You can't.
It seems there is no way from 2.3 on to write a 3G-managing app.
Correct.
You are welcome to try to contribute changes to the AOSP Settings application, or create a new firmware application, that offers the features you seek.
Related
I'm trying to provide certain functionalities for an android phone that could help people in times of emergencies. (These functionalities are dependent on the phone's sensors.) The only/main approach to achieve this seems to be that of developing an app (and I am currently in the process of developing one). But, what concerns me is that the number of people using an application specifically for emergency purposes is quite low. Even if they do install, when "Insufficient Memory" pops up, an emergency app is very likely to be booted out of the phone.
Are there other ways of providing the functionalities/features of an emergency app, without the users having to explicitly install the app? Or should I just stick with the app?
Certain OEMs provide emergency features as part of their settings. Like for example, in a Samsung phone you can toggle to enable the "Send SOS messages", and then, in case of an emergency, press the power button thrice. In what way could I achieve the same?
Any help would be much appreciated...
Thanks in advance!
Without a proper application installed in user device, you cannot provide the functionality you want.
OEM's also have their applications build and packaged with the system image. If you want it, you need to be in contact with them to include your application in new devices.
I have seen many solutions to check if our own app is minimized,running or background.but is there a way to check if another app package is running or minimized so that based on that we can run a code.like an app-locker.Here we need to turn off network for a certain apps according to the user selection on installed apps in device, so when that selected apps are on foreground, network should be disabled when the selected apps are closed or minimized.then enable the network.
Will it be compliant with Google play if we make such an app? because somewhere i read they don't allow apps that interfere with other apps.so confused.
TL;DR: Google doesn't want you to do this, and you shouldn't try.
The old hack that relied on ActivityManager#getRecentTasks() to find out which app is in the foreground was disabled starting in Android 5.0.
App lockers that work on Lollipop are using a new hack involving ActivityManager#getRunningAppProcesses(). How it works is described in this answer. This hack is reportedly broken on Android M.
There's a new UsageStats API from which you might be able to glean a bit of info, but it requires a permission that can only be granted by a system activity. It's documented that this system activity may not be present on all devices. Samsung and LG are among the manufacturers that have reportedly removed this activity from their Lollipop devices, so only system apps will ever be able to use UsageStats.
The bottom line is that Google has shown their commitment to preventing what you're trying to do. Even if you find a temporary solution, you can bet that it will stop working in a future Android version. Eventually, Google will close all the loopholes and your app will be permanently broken. So it's probably a waste of time to write a new app that depends on this capability.
I'm planning to deploy an app on my android smartphone which is supposed to be used by multiple other persons. Now of course I do not want them to do things with the device they are not supposed to do so I informed myself about several different ways to make it as safe as possible (Lock-down apps, Kiosk mode, Mobile-device-management, Code-tweaks and so on).
I found some solutions that look really promising but they all share the same problem that a user could just restart the device and boot it in safe-mode where those helpful apps won't be started. However, there is one exception: I've installed a MDM app called maas360 which somehow manages to apply the restrictions that I defined even in safe-mode, for example by blocking access to the menu settings. How is that even possible? The thing is just that this is not a free app and it offers a huge variety of functions - overall it seems to be a bit excessive for my goals.
So my general question would be: is it somehow possible to restrict access to the safe-mode somehow? Maybe like a password? From what I understand it is not even possible to set a system password for Android devices that you'd have to enter once it boots (except if you set up a password for unlocking the screen first which would then be the same one... very redundant).
Disabling physical switch of volume down (in case of samsung devices) will stop access to safe mode on device. I dont find any other way to do so.
I'm trying to develop an app that would normally be considered to be malware, but the customer's demands are very specific and logical. We have around 50-100 cheapset Android phones that are bolted down, plugged in, and the app is supposed to send some of the sensor data via tcp to a remote server. It sounds simple enough, but there are two features that I struggle with (since I'm not an experienced Android developer, and have never rooted a phone):
#1 The app should be always on. If it crashes, server should get the error report (stack trace), and the app should be restarted after 10 minutes one more time before giving up. Also, the OS could theoretically kill the app (although I did my best to minimize the memory usage). I'd like to somehow handle that as well.
#2 It would be great if the app could be remotely updated, or auto-updated, with no user interaction whatsoever (since there is no conventional user).
To implement #1, I see no other solution than to root the phone (AlarmsManager doesn't seem to work as I expected, and adding another application to take care of the first one just feels wrong). Is there anything I'm missing?
I don't know how to approach implementing feature #2 at all. If I put the app on the market and check the "keep this application always up to date" checkbox while installing it, will that work? I fear that the auto-update would not occur while the service is running, and even if it did, that the OS would not restart the service after installing the update (unless feature #1 is implemented). If I programatically download the latest .apk and open it, I still need the user to click the "Install" button. I'm even considering implementing the updateable part in some scripting language.
Is there a solution to these problems within the limits of Android API?
EDIT: Thank you all for your answers, you've been very helpful. It seems that the only way to make Android behave as a non-user piece of hardware is to root it. That's the only way to do silent auto-updates. Always on can then be implemented by enabling cron (AlarmManager apparently doesn't fire the event in case of service termination via crash, but it could be used by another trivial, non-crashable service to keep the first one running).
For #1 you can use an foreground service. I don't know how often you need to get sensor data, but what's the problem with AlarmManager? I don't see how rooting could help with #1 though. You can't really do #2 without rooting or building your firmware. If you install your app as a system app (in /system/app) you can use a hidden PackageManager to silently install the new version. Using Market/Play autoupdate should work as well, but you have no way to control the update schedule. And, yes, it won't restart your service, but if you use AlaramManager, this shouldn't be a issue.
All in all, stock Android is not exactly an embedded system that gives you full control, so depending on how much time/effort you are willing to spend, you might want to customize it somewhat (or find a custom ROM that gets close to your requirements).
Re: question #2, there are a few open-source (licensed under the Apache Software License 2.0) options you may check and see how it works.
https://github.com/lazydroid/auto-update-apk-client is the android client for the auto update service (i'm affiliated with), which is small, easy to implement and supports silent updates on rooted devices.
https://github.com/commonsguy/cwac-updater is written by Mark Murphy, however it might require you to run your own update server and I'm not sure about silent updates.
I'm wondering if it's possible to develop an android app that will be run in sort of a kiosk mode. The idea is that the user should only be able to interact with the phone through this app.
I understand that an app can be auto-restarted, and things like avoiding incoming calls, could be implemented via a service that would subscribe to the telephony events and would hang up when an incoming call is received. The downside of this is that the usual "answer call screen" would pop up for a short period. The reason behind this is that the stock android app that receives the incoming calls will still be there.
I also understand that, by design, this custom app could be killed at any time by the OS if memory usage gets too low. Although this should only happen if there's a memory leak in any of the running apps.
I'm not sure either if it would be possible to disable the behavior of the physical buttons to access home or settings screens.
I understand that rooting the device and/or creating a custom ROM with modifications would be a safer approach, but also more complex. I'm wondering if a good-enough kiosk mode could be implemented with an android app.
P.S: I'm sorry for reposting these questions, but answers to similar questions are not clear enough.
Make your application be a home screen. That can still be bypassed unless you make your own custom firmware where your application is the system default home screen. We cannot tell you whether being a home screen alone is "a good-enough kiosk mode".
I've been searching for this for days now, nearly every answer is not a complete solution at all (and it's doing my head in)
This link though has the best answer so far
http://thebitplague.wordpress.com/2013/04/05/kiosk-mode-on-the-nexus-7/