終了しないサービスの作り方

[android.ghashimoto]

お世話になっております、橋本です。

現在、サービスを使ってAndroid端末が起動している間はずっと
裏で動き続けるアプリを作成しようとしています。

Intent.ACTION_BOOT_COMPLETED
でサービスを開始

サービスのonDestoy()で再度、自身を起動

上記のやり方で、
「設定」-「アプリケーション」-「実行中のサービス」
から停止された場合には自動でサービスが起動することができる
ようになりました。

しかし、
「設定」-「アプリケーション」-「アプリケーションの管理」
から「強制停止」された際にはサービスのonDestroy()が走らない
ため、サービスを起動することができません。

これを防ぐ方法はないのでしょうか？
そもそもユーザーが停止したいのにそれに反して起動を繰り返すような
アプリを作ることはできないのでしょうか？

よろしくお願いします。

[yuka2py]

ゆぅかです。こんにちわ。

ご質問の趣旨とは異なる返信で恐縮ですが、
サービスを常時起動させたいのには理由があるかと思いますが、
どのような目的や処理をお考えになられているのでしょうか？

その情報を頂けたら角度は違うかも知れませんが、
何かコメントできるかも知れません♪

> そもそもユーザーが停止したいのにそれに反して起動を繰り返すような
> アプリを作ることはできないのでしょうか？

私も知識が浅いのでこの答えは分からないのですが、
アプリの仕様として、あまり良く無いような気はしますです。。
（^ ^;

よろしくお願いいたします。

-- ゆぅか。

2011年6月10日9:19 android.ghashimoto <android.g...@gmail.com>:

> --
> このメールは Google グループのグループ「日本Androidの会」の登録者に送られています。
> このグループに投稿するには、android-g...@googlegroups.com にメールを送信してください。
> このグループから退会するには、android-group-j...@googlegroups.com にメールを送信してください。
> 詳細については、http://groups.google.com/group/android-group-japan?hl=ja からこのグループにアクセスしてください。
>
>

[android.ghashimoto]

ゆぅか様

お世話になります、橋本です。

> どのような目的や処理をお考えになられているのでしょうか？
→現在、考えているのはLogCatから吐かれるログをファイル保存し、一定の
　タイミングでサーバーへアップロードするというものです。
　これだけの処理であれば、何か別のトリガーでサービスを再起動すればよい
　のかもしれませんが、ゆくゆくは携帯端末の制御を行うことができるアプリ
　を作りたいと思っています。

> アプリの仕様として、あまり良く無いような気はしますです。。
→確かに一般の人向けには良くないアプリかもしれませんが、セキュリティの
　ことなど（紛失等）を考えると、需要があるのではないかと考えています。

以上、よろしくお願いします。

[Nkzn]

なかざんです。

セキュリティ面などで「落ちないアプリ」の需要があることを理解した上でですが、

> 「設定」-「アプリケーション」-「実行中のサービス」

> から停止された場合

これはユーザーがかなりの確固たる意志を持って「このサービスを消したい」と思って行う操作なので、

そこまでしてサービスを再起動する必要はないと思います。（誤操作の可能性は低いでしょうし）

少なくとも私はそんなアプリがあったら不愉快です。

ただ、↑の手段で止めない限りは生き続けるアプリ、というのであれば欲しいですね。

// 2009年ごろに実際に「Swift」というTwitterクライアントがあり、

// Serviceでタイムラインの監視を行ってくれていたのですが、

// 実際に「実行中のサービス」から切らないと延々とリプライ通知を出してくるアプリでした。

// 当時のSwiftにかなりの不快感を覚えたので、今回も同じ（もしくはそれ以上の）状況に

// ならないよう、失礼ながら強めの忠告をさせていただいています。

以上、ご参考までに。

--Yukiya Nakagawa

[android.ghashimoto]

なかざん様

お世話になります、橋本です。
なるほど、ご指摘いただいた通りユーザー（持ち主）が「確固たる意志」を
もってサービスを停止させたい場合にも停止ができない状況は良くないですね。
ご忠告ありがとうございます。

ただ、悪意あるユーザー（拾い主）に勝手にサービスを停止され、悪用される
状況は避けたいです。従って、ユーザー（持ち主）にはアプリ側でサービスの
ON/OFFを切り替えられる口を用意（パスワード認証付）し、そこからサービスの
停止を行えるようにしたいと思います。

貴重なご意見ありがとうざいました。

以上です。

[awwa]

あわと申します。

AlarmManagerでstartService()→次のalarmセットみたいな感じで定期的に起動ですかね。
チェック頻度を高くするのはリソース的に厳しいかとおもいますが。

マナー的な問題は他の方にお任せで。

2011/06/10 13:54 "Nkzn" <yn.ai...@gmail.com>:

> --
> このメールは Google グループのグループ「日本Androidの会」の登録者に送られています。

> To view this discussion on the web visit https://groups.google.com/d/msg/android-group-japan/-/oGMp6IiO1jwJ.

[yuka2py]

ゆぅかです。こんにちわ。

ご説明ありがとうございます。お手数をお掛けしましたです。
LogCat の出力を取り続けるというと Service はやっぱり起動し続けて
おく必要がありそうですね（たぶん）。

以下、きっと既に検討されたことだったり、検討違いだったりで、
あんまり有用じゃないかも知れませんが...

ユーザーによる強制停止以外にも、メモリー不足などで onDestroy() を
通らずに Service が無くなってしまうこともあるらしいですね。
そんなこともあり、私自身は、Serviceを確実に落ちないようにするのは無理
だろうな、と思っています。

それを踏まえて、「なるべく起動し続ける」という方針でしたら、
Alarm で定期的に startService というのが良いかと思います（月並みですが ^ ^;）。
それで、この場合、ログ取得の処理は、onCreate に書く感じでしょうか。
（Service がシステムから kill されると onStart が呼ばれない場合もあるそうなので）。

という月並みの回答できなくてすみませーん！

-- ゆぅか。

2011年6月10日13:29 android.ghashimoto <android.g...@gmail.com>:

[大垣憲俊]

大垣です。

単なる思いつきですが。

アプリを２つ使って相互に監視し、同時には強制終了できないので、

一方のアプリが強制終了されたら、他方のアプリからそれを再起動する、みたいな。

[mamoru info]

まもるです。

何となく、何を作りたいか、（外れているかもしれませんが）分かる気がします。

ただし、アプリ開発のために、モバイルの基本的な技術論を理解されると良いと思います。

・リアルタイムOSの特性及びその中でのAndroidとは、どのような特性を持っているか？

・そもそも、電池消耗量をどう考えるか？

・そもそも、送出したいデータの通信手段とその方法は何が最適か？

など、恐らく、色々な面で、簡単には開示されないと思います。

その上で、アプリ実現を優先したがために、セキュリティに落とし穴があっては、実現性がなくなると思います。

ご参考までに。。。

2011年6月10日14:22 android.ghashimoto <android.g...@gmail.com>:

--
このメールは Google グループのグループ「日本Androidの会」の登録者に送られています。

[トムキャット]

トムキャットです。

サービスをずっと動かし続けることをユーザーに説明できる理由がある場合、

startForeground

が使えると思います。OnGoingのNotificationでそのことを伝える必要があります。SDKの説明にもある通り、バックグランドで動き続
ける音楽プレイヤーはその良い例だと思います。

[鯖缶戯言]

鯖缶こと服部です。

セキュリティ要件で「落ちないアプリ」とのことですが、エンドユーザー側のいかなる操作に対応するという
設計方針はいかがな物でしょうか？

「落ちないアプリ」に障害が発生があり永続的に・・・なことも考えられますよね。

＃紛失の場合は、悪意がある人であればそもそもSIMカードを抜かれrootを取られるとなんでもOKなので
＃アプリ側で云々はそもそも無理があると思うので。

2011年6月10日16:12 mamoru info <info....@gmail.com>:

[Makoto Yamazaki]

山崎です。

ひとつ気になる点があります。
Android3.1の変更点に、アプリケーションのstoppedステートの導入というのがあります。
stoppedなアプリにはシステムのブロードキャストが飛ばなくなるようなのですが、stoppedとして扱われる場合の一つにユーザーが停止した場合というのが含まれています。
なのでもしかしたらユーザーが明&#3103> 鯖缶こと服部です。

[amay 077]

おくやま と申します。

AlarmManager 、自作アプリで使っているんですが、タスクキラーやアプリの強制停止時にキャンセルされてしまいました。

あと、

Llama - https://market.android.com/details?id=com.kebab.Llama というアプリが希望されてる動きをしています。

DDMS などでどれだけプロセスを殺しても、数秒後に立ち上がってくるのです。

どうやってるのかなーと思いつつ、ご参考になれば。

--

http://twitter.com/amay077

[android.ghashimoto]

あわ様　ゆぅか様

お世話になります、橋本です。
ご指摘いただいたAlarmManagerを使った方法で試してみました。
結果はAlarmManagerに設定していても

「設定」-「アプリケーション」-「アプリケーションの管理」

で「強制停止」された場合には、設定された次のスケジュールが
実行されませんでした。

具体的には、

１．Activity起動
　　起動したActivityからService起動
　　ServiceのonStartCommandで次回の自サービスの起動を設定
　　定期的にonStartCommand内での出力ログがLogCatに出力されることを確認
　　「設定」から「強制停止」
　　以降、LogCatにonStartCommand内からのログ出力されず…
　　ActivityManagerから以下のログが出力されました
　　INFO/ActivityManager(153): Force stopping package
com.unstoppableService uid=10141
　　WARN/ActivityManager(153): Scheduling restart of crashed service
com.unstoppableService/.MyService in 5000ms
　　INFO/ActivityManager(153): Force stopping service
ServiceRecord{30a238d0 com.unstoppableService/.MyService}

２．Activity起動
　　起動したActivityからService起動
　　ServiceのonStartCommandでsendBroadcast
　　Manifestファイルで定義したBroadcastReceiverでintentを受信
　　BroadcastReceiverのonReceive内でサービス起動
　　BroadcastReceiverのonReceive内で次回のsendBroadcastを設定
　　定期的にonStartCommand内での出力ログがLogCatに出力されることを確認
　　「設定」から「強制停止」
　　以降、LogCatにonStartCommand内からのログ出力されず…
　　Force stopping package com.unstoppableService uid=10141
　　Scheduling restart of crashed service
com.unstoppableService/.MyService in 5000ms
　　 Force stopping service ServiceRecord{309cd0d8
com.unstoppableService/.MyService}

こんな感じです(^^;

私のやり方がまずいのか、はたまた最初から無理なのか、
このやり方では「強制停止」されたアプリ内でセットしたものはキャンセル
されるようです。

以上です。

[android.ghashimoto]

大垣様

お世話になります、橋本です。
この方法は考え付きませんでした。
最初にアプリを２つインストールする手間がありますが、
同時に落とされることはなさそうですね。

貴重なご意見ありがとうございました。

以上です。

[android.ghashimoto]

まもる様

お世話になります、橋本です。
「モバイルの基本的な技術論」ですか。
ご指摘いただいた内容については今まで深く考えたことがありません
でした。最近、Androidの開発に携わるようになり、それまではモバイル
向けの開発を行ったことがなく、皆様にとっての常識を理解していない
部分も多々あると思います。

もう一度、１から考えていきたいと思います。
ありがとうございました。

以上です。

[丹羽直也(MineStudio)]

こんにちは、丹羽です。

C2DMをトリガーとしてサービスの起動チェックを行うとかではダメでしょうか？

2011年6月10日19:03 android.ghashimoto <android.g...@gmail.com>:

--
Android セキュリティ部(Android Security Japan)
丹羽 直也

Twitter : @mine_studio
Site: http://www.mine-studio.com/
Blog: http://blog.mine-studio.com/

[android.ghashimoto]

トムキャット様

お世話になります、橋本です。

> startForeground
このメソッドの存在を知りませんでした。ありがとうございます。
しかし、試してみたところ「強制停止」で通知アイコンが消え、サービスが
終了してしまいました。

「強制停止」を押下しても動作し続けるというのは無理なような気がして
きました…もう一度本当にそのような動作をする必要があるのかを含めて
考え直そうと思います。

ありがとうございました。

以上です。

[android.ghashimoto]

鯖缶こと服部様

お世話になります、橋本です。

> 「落ちないアプリ」に障害が発生があり永続的に・・・なことも考えられます
よね。
→確かにご指摘いただいたような状況に陥る可能性はあります。
　最終的にアンインストールするには工場出荷時に戻す以外に方法がないという
　状況は良くないと思います。

> ＃紛失の場合は、悪意がある人であればそもそもSIMカードを抜かれrootを取
られるとなんでもOKなので
> ＃アプリ側で云々はそもそも無理があると思うので。
→これも確かにそうだと思います。しかし、悪意のある人の手に渡ったときに
　端末自体は諦めるとして、中のデータを悪用される状況は避けたいと思い、
　このような質問をさせていただきました。

しかし先のメールにも書いたようにもう少し考えなければいけないようですね。
貴重なご意見ありがとうございました。

以上です。

[android.ghashimoto]

山崎様

お世話になります、橋本です。
「stoppedステートの導入」ですか。
すいません、初耳でした。。。やはり、ユーザーの意図に反してサービスを起動
し続けるというのは無理なのでしょうかね。

ご指摘ありがとうございました。

以上です。

[android.ghashimoto]

おくやま様

お世話になります、橋本です。
やはりAlarmManagerではダメですか。。。
貴重なご意見ありがとうございます。

> DDMS などでどれだけプロセスを殺しても、数秒後に立ち上がってくるのです。
→これは、DDMSのDevicesの一覧からプロセスを殺すという認識でよろしかった
　でしょうか？それであれば、ServiceのonDestroyにて再度、自サービスを起動
　すれば、数秒後に再起動されます。

以上です。

[yuka2py]

ゆぅかです。こんばんわ。

他の方のコメントにもありましたので、
Alarm は強制停止に敵わないんですね。
知りませんでした。。。

お力になれずすみません！

私もこのあとのスレッドを見て勉強させていただきます！

お騒がせしましたー。(*´ω｀*)

-- ゆぅか。

2011/06/10 19:04 "android.ghashimoto" <android.g...@gmail.com>:

[android.ghashimoto]

丹羽様

お世話になります、橋本です。
やはり、常に起動し続けるのではなく、何かをトリガーにして起動する
方法が良さそうな感じですね。
ありがとうございます。

会の皆様
連投失礼しました。
しかし、貴重なご意見が聞くことができ、大変参考になりました。
ご意見を下さった皆様ありがとうございました。
サービスを起動し続ける以外の方法で要件が満たせないかもう一度
考えていこうと思います。

ありがとうございました。

以上です。

[takayuki hirano]

橋本様

お疲れ様です。するめです。

私もサービス常駐が必要なアプリの作成を行っているため参考にさせていただいております。

アプリケーション管理の停止で起動してこなかったとのことですが、

こちらではAlarmManagerで再起動することができています。

具体例との違いをちょっと確認してみます。

以上です。

2011年6月10日19:37 丹羽直也(MineStudio) <naclub...@gmail.com>:

[android.ghashimoto]

するめ様

お世話になります、橋本です。
えっ？本当ですか！！
私の確認の仕方がまずかったのですかね(^^;;

> 具体例との違いをちょっと確認してみます。
→よろしくお願いします。

以上です。

[android.ghashimoto]

ゆぅか様

お世話になります、橋本です。
いえいえ、とんでもありません！
私の方こそ、かえって皆様を混乱させているようで…

> 私もこのあとのスレッドを見て勉強させていただきます！
→もうしばし、お付き合いくださいませｗ

以上です。

[鯖缶戯言]

鯖缶こと服部です。

> →これも確かにそうだと思います。しかし、悪意のある人の手に渡ったときに
> 　端末自体は諦めるとして、中のデータを悪用される状況は避けたいと思い、
> 　このような質問をさせていただきました。

暗号化なら先日からcamellia-androidライブラリを無償公開しています。
http://code.google.com/p/camellia-android/

取り敢えず、Java側のArrayList<String>形式で依頼された内容をエンコードしArrayList<byte[]>に返却します。
デコードは逆でArrayList<byte[]>をArrayList<String>に変換します。

まだ外部ファイルに関しては実装途中で、未公開ですが来週中には更新できるかなと思っています。
一応、Androidセキュリティ部でも活動していまして、ABCでAndroidセキュリティ部の枠でLTする予定です。(^^;

＃宣伝になって済みません。

一考して頂ければ幸いです。

2011年6月10日20:17 android.ghashimoto <android.g...@gmail.com>:

[android.ghashimoto]

鯖缶こと服部様

お世話になります、橋本です。
ライブラリのご紹介ありがとうございます。
ブログも拝見させていただきました。

# サーバー管理者の略で鯖缶なんですね
# 鯖缶が大好きな方かと思ってましたｗ　失礼しました

以上です。