Google Android - это несложно

Всем привет.
Есть потребность в создании функции приложения, которая будет противодействовать входу в настройки. Т.е. здесь надо реализовать две задачи:
1. Отловить момент, когда пользователь откроет настройки
2. Убить процесс настроек, либо какое-то другое действие с процессом реализовать, но чтобы доступ в настройки был закрыт.
(Важное замечание: никаких кастомных андроидов и рутовых телефонов)
Обе функции, я не знаю и не понимаю как реализовать. нагуглить что-то толковое, тоже не удалось, разве что только по второму вопросу.

Process.sendSignal(pid, Process.SIGNAL_KILL);
ActivityManager.killBackgroundProcesses(PackageName)

...

The second API works by telling the ActivityManager that you wan to kill processes associated with a specific Package. This API gets around the need for your UID to match the UID of the process because it requires the user to accept the KILL_BACKGROUND_PROCESSES permission. This permission signals to the OS that an app has been approved by the user as a task killer. When a task killer wants to kill an app, it tells the OS to do it getting around the problem of only being able to kill processes that you own.

http://stackoverflow.com/a/8819618/2337544

Я так понимаю, мы всё таки можем послать флаг на закрытие процесса, при этом миновать ограничения линукса на уничтожения только UID процессов. Не знаю еще, работает это или нет.
Может кто знает какую-либо информацию более подробную по данным вопросам?
И еще, возможно ли также блокировать запуск других программ, а также их доступ к сети?

P.S. я общался с человеком, который меня заверил, что такое возможно. К примеру приложение МТС координатор позволяет блокировать изменения настроек, а также ограничивать запуск приложений.

Еще нужно предусмотреть, чтобы приложение нельзя было удалить

И что-бы СМС на платные номера посылало)

Mikhail_dev писал(а):Всем привет.
Есть потребность в создании функции приложения, которая будет противодействовать входу в настройки. Т.е. здесь надо реализовать две задачи:
1. Отловить момент, когда пользователь откроет настройки
2. Убить процесс настроек, либо какое-то другое действие с процессом реализовать, но чтобы доступ в настройки был закрыт.
***

1. как варриант:
-а) Если пользователь открыл настройки, то твое приложение ушло в бэкграунд, т.е.:
[syntax=java5]
public void onWindowFocusChanged(boolean hasFocus) {
super.onWindowFocusChanged(hasFocus);
[/syntax]
и если гад(пользователь) такое сделал, то ты можешь к примеру:
[syntax=java5]
Intent closeDialog = new Intent(Intent.ACTION_CLOSE_SYSTEM_DIALOGS);
sendBroadcast(closeDialog);
[/syntax]
-б) Наплевать на жизнь батареи пользователя и запускать каждую секунду:
[syntax=java5]
String packageName;
String className;
ActivityManager amen = (ActivityManager)getBaseContext().getSystemService(Activity.ACTIVITY_SERVICE);
packageName = amen.getRunningTasks(1).get(0).topActivity.getPackageName();
className = amen.getRunningTasks(1).get(0).topActivity.getClassName();
[/syntax]
и если будет обнаруженна активность пакета: com.android.settings - ругайся как хочешь...

2) ну собственно убивать не обязательно, ты можешь к примеру заметив что запущен процесс запустить из сервиса интент который вернет насильно твое приложение в foreground. В любом другом случае, чтобы влиятть на поведение системных апов нужен рут либо как в 4.4 "повышенные" привилегии приложения(не помню как оно называется, но доступно только в 4.4)

P.S. но вообще я давно не интересовался и может что -то более адекватное есть... Но опять же если это что -то вроде корпоративного девайса над которым нужен контроль, то тут наиболее логичное решение - кастомный rom.

Как варриант можно попробывать добавить себя обработчиком action settings(фиг его знает как правильно это сделать) и в ответ не делать ничего, но опять же - только на "аля" корпоративный девайс, т.е. с физическим доступом админа, врятли юзер сам тебе позволит заменить собой системный конфиг.

И еще, возможно ли также блокировать запуск других программ, а также их доступ к сети?

без рута, либо физического доступа к девайсу - нет. Это как с кросдоменными запросами в web, если разрешить - будут проблемы. Более того если установленны антивирусы - это дополнительный фильтр такого поведения, т.к. по сути твое ПО уже работает, как вирус по отношению к системе.

Кстати "МТС Координатор" использует "Получение данных о запущенных приложениях" - потому скорее всего просто выводит себя в foreground, иначе он не может не дать доступа к настройкам, но вообще фиг их знает.. надо как то установить и посмотреть его активность, либо код.

Но вообще я бы удалил приложение с таким поведением... мало того, что не нужная мне активность сервиса, так еще и настройки открыть не дает
По поводу kill процесса в inux, ты можешь только pkill выполнить и думаю, что работать будет, но это при условии, что settings запускается от имени текущего пользователя, чтобы выполнить kill - нужны root права.

на войне как на войне, так ему

потому скорее всего просто выводит себя в foreground, иначе он не может не дать доступа к настройкам, но вообще фиг их знает.. надо как то установить и посмотреть его активность, либо код.

Угу, я в данный момент ожидаю доступа туда. после опытов отпишусь. Спасибо за отзывы.

Mikhail_dev писал(а):

потому скорее всего просто выводит себя в foreground, иначе он не может не дать доступа к настройкам, но вообще фиг их знает.. надо как то установить и посмотреть его активность, либо код.

Угу, я в данный момент ожидаю доступа туда. после опытов отпишусь. Спасибо за отзывы.

Кстати опять таки зачем тебе запрещать доступ в настройки, ты же можешь просто отслеживать их изменения, к примеру если пользователь отключил GPS - запускать mp3 файл и сказать все, что о нем думаешь Или просто к примеру оператору передать, что кто -то филонит...

altwin писал(а): Кстати опять таки зачем тебе запрещать доступ в настройки, ты же можешь просто отслеживать их изменения, к примеру если пользователь отключил GPS - запускать mp3 файл и сказать все, что о нем думаешь Или просто к примеру оператору передать, что кто -то филонит...

Или просто к примеру оператору передать, что кто -то филонит...

И так все настройки прослушивать? Оно того не стоит. Приложение корпоративного характера, так что вопрос довольно таки актуальный. К тому же никто не отменял такую вещь, как "на дурака". Скажет потом юзер, мол, случайно нажал или еще что-то.

Mikhail_dev писал(а):

Или просто к примеру оператору передать, что кто -то филонит...

И так все настройки прослушивать? Оно того не стоит. Приложение корпоративного характера, так что вопрос довольно таки актуальный. К тому же никто не отменял такую вещь, как "на дурака". Скажет потом юзер, мол, случайно нажал или еще что-то.

Так зачем все, тебе по сути может быть нужно совсем не много - доступ к сети, gps и что то еще... в общем только то от чего зависит работа, а запрещать пользователью менять мелодию и ставить голых теток в качестве обоев - не гуманно
В любом случае android -это почти linux и роли пользователей важны. Для того, чтобы запретить доступ к чему -то, тебе нужно понизить привилегии пользователя, т.е. пользователь должен работать не из стандартной группы. В стандартных ланчерах это не предусмотренно и все, что ты можешь сделать - как то реагировать на вызов настроек по сути заспамивая пользователя, но это поведение вируса и разное ПО может по разному реагировать уже на тебя. Тебе проще установить кастомный ланчер в котором не будет как таковой возможности входа в настройки, а дефолтный удалить, но опять таки нужен рут. Все остальное легко обходится и пользователь как минимум может использовать/установить чужое приложение которое тоже будет менять настройки, а его поведение тебе не подконтрольно... т.е. тебе нужно отслеживать состоянии датчиков, т.е. gps активен - ок, изменилось состояние - паника... и т.д.

P.S. с точки зрения бизнеса, тебе не запрещать нужно(т.е. ывнуждать пользователя искать не предусмотренный ошибки), а вести логи, т.е. изменил настройки - скажи, что так нельзя и запиши в лог. Бизнесу важно не столько гаррантировать работу, сколько найти ответсвенных во время сбоя. Т.е. если пользователь сменил настройки тебе не запрещать нужно, а оповещать его начальника, а тот уже пусть разбирается и платит тебе за поддержку, т.е. возврат настроек.

altwin писал(а):Т.е. если пользователь сменил настройки тебе не запрещать нужно, а оповещать его начальника, а тот уже пусть разбирается и платит тебе за поддержку, т.е. возврат настроек.

Верно сказано. Помню, когда работал 1С программистом, программисты внедряющие 1С так и говорили, чем городить кучу проверок в коде от хитрожопых пользователей, проще решить это на административном уровне. Пару раз премии лишится, больше не будет.

ААА, одинэсник!

[syntax=cpp]
Процедура ОбработкаВнешнегоСобытия(Кто,Что,Зачем)
Если Кто="LRC_Modem" Тогда
Если Что="LRC_Modem" Тогда
Сообщить(Зачем);
КонецЕсли;
КонецЕсли;
КонецПроцедуры //ОбработкаВнешнегоСобытия
[/syntax]

P.S. подумаю на счет логгирования. Кстати, а нагружают ли как-то батарею эти слушатели, которые будут мониторить настройки?

Mikhail_dev писал(а): P.S. подумаю на счет логгирования. Кстати, а нагружают ли как-то батарею эти слушатели, которые будут мониторить настройки?

Если проверять на запуск пакета, то да, потому как постоянно сервис будет запрашивать список пакетов и читать его. Если же ты просто ожидаешь системные события, как вкл/выкл датчика gps или подключение к другой сети, то по сути это колбек, событие итак вызывается в системе и ты просто добавляешь обработчик, который до "возбуждения" ничего не делает.