Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 39
Больше похоже на иструкцию, как сделать смс-локер. «Ваш планшет заблокирован! Т.к. на вашем планшете нет SIM, вам придется отправить СМС с вашего телефона на номер....»
И кстати вы будете убирать ланчер из /system/app?
Подкину вам идею, можно удалить также перемесить апдейтер…
Только такие переносы в System/app череваты чем, что если кто-то сделает вайп у него не окажется ланчера например.
И кстати вы будете убирать ланчер из /system/app?
Подкину вам идею, можно удалить также перемесить апдейтер…
Только такие переносы в System/app череваты чем, что если кто-то сделает вайп у него не окажется ланчера например.
Чтобы сделать вайп придётся либо иметь доступ к хардварным кнопкам, либо к системным настройкам. Туда и туда доступ можно ограничить.
kiosk-mode эт полезная штука если вздумалось сделать какойнить информационный терминал в враждебной технике среде (например в универе :) ). В свое время активничал в этом направлении, но к сожалению так полной блокировки и не добился.
Кнопка настроек на клавиатуре отключается… в настройках :)
Вот для примера как это сделано (2 раза) на другой платформе:
1) http://joris.kluivers.nl/blog/2012/03/02/kiosk-mode-for-ios/
2) http://www.apple.com/ios/ios6/#accessibility
1) http://joris.kluivers.nl/blog/2012/03/02/kiosk-mode-for-ios/
2) http://www.apple.com/ios/ios6/#accessibility
Спасибо за информацию, но… это настолько сильно ломает UX и не соответствует общему стилю приложений, что совсем не понятно, в каких благородных целях стоит это делать.
Ну представьте, сервис терминалов оплаты мобилников. Представили? Теперь переносите это на планшет. Вы бы очень не хотели, чтобы в работу терминала каким-то образом можно было бы вмешаться. Согласны? Конечно, как вариант можно скачать исходники андроида, начать компилять и портировать всё, но а если на это нет времени, сроков и бюджета? Остаётся искать обходные пути…
Это кстати не очень хорошо. Экран планшета не является антивандальным. Удар тяжелым предметом разнесет и сенсор и матрицу и все что под ними. Гораздо лучше для этого будет использовать маленький linux PC (в виде флешки например) и к нему уже сенсор с защитой и экран. Да и даже 10 дюймов будет маловато для терминала оплаты. А если смотреть по цене 10 дюймовый в общем то можно и за 100$ купить, но раздолбают очень быстро. Вроде за 25$ есть usb пк. А там уже и экран недорогой и тач под него думаю в 75 баксов можно уложиться, правда защита тача будет подороже стоить.
Полностью согласен. Мы думали об этом. Но мы выбрали именно уже готовый планшет с андроидом потому что во-первых времени на разработку первого прототипа уйдёт гораздо меньше, во-вторых планшет будет размещаться не на улице, а в закрытых местах, где он будет более-менее под присмотром. Вся вина будет лежать на том, кто разнесёт планшет.
1. Так если специально подбирали планшет. Почему не подобрали, для которого уже есть дрова в аосп? Тогда бы вы спокойно могли менять все что захотите.
2. Зачем лепить «приложение», когда надо делать ланчер? Таким образом, сможете ограничить практически все, не прибегая к хакам и руту.
2. Зачем лепить «приложение», когда надо делать ланчер? Таким образом, сможете ограничить практически все, не прибегая к хакам и руту.
Я вам другой пример приведу — меню для ресторанов. Антивандальным его не сделать — планшет должен быть «стандартным», но и доступа никуда не должно быть.
Для терминала по оплате было бы куда проще сделать «антивандальную» рамку, закрывающую нижнюю панель. Раз уж доступ к хардварным кнопкам блокируется физически, то и это проблемой не должно стать. И выглядит куда проще :)
а SYSTEM_ALERT_WINDOW разве не проще для этих целей?
Для каких именно целей? Не понял Вас…
для того чтобы отрисоваться поверх всех окон и не давать себя закрыть. приложения-локеры используют именно этот способ, например, play.google.com/store/apps/details?id=com.thinkyeah.smartlockfree
При наличии рута переносить системные аппы в другое место тоже не тру (на многих девайсах системный раздел вообще не перемонтируется на rw), к тому же при переносе может выполниться удаление приложение с потерей всех данных. Более правильно — отключать их через pm (package manager): pm disable com.android.launcher2. Соответственно, enable для включения обратно. Данные сохраняются, но приложение словно удалено, оно может встретиться лишь в управлении приложениями (если было отключено системное приложение).
Часть системных диалогов (в т.ч. список RecentApps) рисует процесс systemui в составе почти одноимённого пакета, так же успешно отключаемый.
Часть системных диалогов (в т.ч. список RecentApps) рисует процесс systemui в составе почти одноимённого пакета, так же успешно отключаемый.
Посмотрите как этот функционал реализован в SiteKiosk для Android:
www.sitekiosk.com/SiteKiosk/Default.aspx#android-tab
Может что-то Вам станет понятней.
www.sitekiosk.com/SiteKiosk/Default.aspx#android-tab
Может что-то Вам станет понятней.
Недавно столкнулся с проблемой — нужно было убрать злосчастный status bar в ICS и JB. Действительно, решение с «service call» годится только для HoneyComb. В ICS и других решение намного более ужасное:
"while 1; do killall com.android.systemui; sleep 1; done"Какой ужас! Зачем старательно убивать процесс, восстанавливаемый системой, если можно его отключить (см выше). Хотя как ведёт себя отключение на планшетах, не знаю.
Да, как раз на планшетах все и непросто. В некоторых прошивках есть в настроках возможность отключить, но тут доступа к прошивке не было как раз, и в меню пункта такого не было. А «pm disable» не дает никакого эффекта — статус бар продолжает гордо выполнять свои функции. Очень надеюсь, что ситуацию изменят со временем. Потому что такое стыдно показывать даже :)
ну, если pm list доступен обычному пользователю, то pm enable/disable имеет результат только при выполнении с системными правами, а такое можно обеспечить рутом (и выполнять через su), или сделать свою программу системной, но для этого она должна иметь системный же uid в манифесте и системную подпись, что можно добиться сборкой всей системы вместе со своим приложением, или переподписью всей системы тем же сертификатом, что использовался для приложения. В любом случае получается, что нужен или рут, или кастомная прошивка, что не всегда возможно.
Хотя, если вы успешно вызывали kilall, значит, системные права уже есть (от пользователя системный процесс, понятно, не убить). Ещё замечу, что в некоторых случаях отключение этого пакета заметно после рестарта системы или, опять же, убийства процесса (но не факт).
Хотя, если вы успешно вызывали kilall, значит, системные права уже есть (от пользователя системный процесс, понятно, не убить). Ещё замечу, что в некоторых случаях отключение этого пакета заметно после рестарта системы или, опять же, убийства процесса (но не факт).
Ой, простите, глупость напечатал. Конечно же
while true, т.к в баше while 1 вовсе бессмысленно.
Может кому поможет:
На ICS и выше для скрытия системного (навигационного) меню мне помог следующий код (нашел где то на stackoverflow):
Для запуска:
На ICS и выше для скрытия системного (навигационного) меню мне помог следующий код (нашел где то на stackoverflow):
try{
//REQUIRES ROOT
Build.VERSION_CODES vc = new Build.VERSION_CODES();
Build.VERSION vr = new Build.VERSION();
String ProcID = "79"; //HONEYCOMB AND OLDER
//v.RELEASE //4.0.3
if(vr.SDK_INT >= vc.ICE_CREAM_SANDWICH){
ProcID = "42"; //ICS AND NEWER
}
//REQUIRES ROOT
Process proc = Runtime.getRuntime().exec(
new String[]{"su","-c",
"service call activity "+ ProcID +" s16 com.android.systemui"});
proc.waitFor();
} catch(Exception ex) {
Toast.makeText(getApplicationContext(), ex.getMessage(), Toast.LENGTH_LONG).show();
}
Для запуска:
try {
Runtime.getRuntime().exec(
new String[]{"am","startservice","-n",
"com.android.systemui/.SystemUIService"});
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Kiosk Mode приложения на Android