(57)【特許請求の範囲】
【請求項１】
各種のアプリケーションが実行されるスマートフォンに格納された安定化ソフトウェアにより実行される方法であって、
前記スマートフォンが実行する前記アプリケーションの挙動を監視する動作監視手順と、
前記アプリケーションの挙動が予めアプリケーション自身により前記安定化ソフトウェアに登録された挙動と異なる場合には、当該アプリケーションの再起動を実施する再起動手順とを備えることで、
前記アプリケーションの安定稼働を実現することを特徴とするスマートフォンの動作安定化方法。
【請求項２】
前記動作監視手順は、
スマートフォンが実行するアプリケーションの挙動についてのログ情報を定期的にスマートフォン内の不揮発性保存領域に追記し、
予め登録された前記アプリケーションの挙動についての情報と合致しているかを定期的に確認することで実行する
請求項１に記載のスマートフォンの動作安定化方法。
【請求項３】
スマートフォンが実行するアプリケーションに対して、前記アプリケーション自身により予め登録された情報に記載のリクエストを送信し、アプリケーションにより登録された前記情報に記載の応答の有無を確認する応答監視手順を備え、応答がない場合に当該アプリケーションの再起動を実施する
請求項２に記載のスマートフォンの動作安定化方法。
【請求項４】
前記安定化ソフトウェアは、前記安定化ソフトウェア自身とスマートフォンの状態を定期的に監視する機能を有し、異常を検知した場合に、前記安定化ソフトウェアまたはスマートフォンそのものの再起動を行う手順を備えた
請求項３に記載のスマートフォンの動作安定化方法。
【請求項５】
前記安定化ソフトウェアは、定期的にスマートフォンの状態を監視し、前記状態及び時刻情報から異常を検知した場合に、前記スマートフォンの再起動を行う手順を備えた
請求項３に記載のスマートフォンの動作安定化方法。
【請求項６】
スマートフォンの状態に関わらず、定期的にスマートフォン自体を再起動する手順を更に備えた請求項５に記載のスマートフォンの動作安定化方法。
【請求項７】
請求項１乃至請求項６のいずれか１項に記載の各手順をコンピュータに実行させることを特徴とする動作安定化プログラム。
【請求項８】
各種のアプリケーションが実行されるスマートフォンに安定化ソフトウェアを格納することで構築される動作安定化装置であって、
前記アプリケーションに対して前記安定化ソフトウェアを利用するためのインタフェースを提供するアプリケーションインタフェース部と、
前記アプリケーションについての起動中のアプリ挙動を取得し、前記アプリ挙動が予めアプリケーション自身により登録されたアプリ挙動と異なる場合に当該アプリケーションの再起動を実施するアプリ動作監視部と、
前記アプリケーションに対し定期的にリクエスト送信し、予め登録されたリクエストの応答内容と、前記アプリケーションからの応答内容を確認し、応答ない場合に該アプリケーションの再起動を実施するアプリ応答監視部と、
定期的又はスマートフォンの電源オン／オフ検知時に、時刻情報とともに前記スマートフォンの状態（定期実行時／再起動検知時／バッテリー不足による停止検知時等）を保存領域に書き出すハートビート部と、
前記安定化ソフトウェアに実装され、前記状態及び時刻情報から前記スマートフォンの異常を検知した場合に、前記アプリ動作監視部、アプリ応答監視部及びハートビート部を再起動するハートビート監視アプリ部と、
を備えたことを特徴とする動作安定化装置。
【請求項９】
スマートフォン自体を定期的に再起動する定期再起動部を備えた請求項８に記載の動作安定化装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、スマートフォンやタブレット型端末（以下、単にこれらを総称してスマートフォンと呼ぶ）上で動作するアプリケーションソフトウェア（以下、単にアプリと呼ぶ）を長時間連続稼働させる状況において、アプリの安定動作を担保するための動作安定化方法、動作安定化プログラム及び動作安定化装置に関する。
アプリの安定動作とは、数日や数ヶ月以上にわたり、アプリが連続稼働している環境において、数ヵ月後にアプリに対しユーザ操作や他のシステムからのリクエストがあった場合にも、アプリが起動した直後と同様に、アプリが応答を返すことができる状態を指す。
【背景技術】
【０００２】
近年、スマートフォンには、多種多様なアプリが搭載可能となっている。また、スマートフォンは搭載するアプリにより機能を拡張し、様々なサービスが実現できる特徴を持つ。本拡張性により、例えば、現在専用に開発された機器等でサービスを実現している、ネットワーク(以下、単にNWと呼ぶ)の遠隔監視や小売業で利用されるPOS端末を、スマートフォンとアプリで代用することも考えられる。
【０００３】
上述したスマートフォンの利用例によれば、専用端末と同等もしくは利用例の使用に耐えうる程度に、アプリが安定動作する必要がある。しかしながら、アプリを安定動作させることは、スマートフォンのオペレーションシステム（ＯＳ）そのものが持つ不具合や、アプリの不具合等により非常に困難という課題がある。
非特許文献１には、スマートフォンの中で最も多く使われているオペレーションシステムの１つであるAndroid(Google Inc.の商標)の不具合（バグ）の報告件数の推移を根拠に、バージョンアップを繰り返す度に、ＯＳそのものの不具合が増加傾向にあることが報告されている。したがって、ＯＳの不具合を完全に無くすことは困難な状況であることが認識されている。
【０００４】
また、非特許文献２には、スマートフォン上で発生するフリーズ(freezes)や自己再起動(self-reboot)、クラッシュ(crashes)、ハング(hangs)を検知する手順が開示されている。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】Amiya K. Maji, et al., "Characterizing Failures in Mobile OSes: A Case Study with Android and Symbian," Proc. of ISSRE 2010, 21th IEEE International Conference.
【非特許文献２】Marcello Cinque, "Enabling On-Line Dependability Assessment of Android Smart Phones," Proc. of DSN-W 2011, 41st IEEE/IFIP International Conference
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、非特許文献２に記載の技術は、スマートフォン上で不具合イベントが発生したことをシステムが検知するのみであり、また、不具合イベント時には、スマートフォンの利用者がスマートフォンを操作し、電源ボタン長押しによる電源のオン／オフやバッテリーの抜き差しを実行する必要がある。
したがって、上述の利用例のように、遠隔監視の対象拠点に設置される場合や既設のＰＯＳ端末の代替とする場合には、スマートフォンを操作可能な管理者がスマートフォンの近くにいるとは限らず、利用者による電源のオン／オフ等の操作が期待できないために、非特許文献２に記載の技術の利用が難しいという課題があった。
【０００７】
これらの状況を考慮すると、通常スマートフォンのＯＳ自体やアプリについては、不定期かつ突然にフリーズ(freezes)や自己再起動(self-reboot)、クラッシュ(crashes)、ハング(hangs)する可能性がある（不具合イベントが発生する）ため、不具合イベントの発生を前提として、不具合イベント発生後も継続してアプリが機能提供できるような仕組みを実現する必要がある。
【０００８】
本発明は上記実情に鑑みて提案されたもので、スマートフォンにおいて、フリーズや自己再起動、クラッシュ、ハングの発生を前提とし、スマートフォン自身で正常動作を維持することで、スマートフォン上で実行されるアプリが連続して安定稼働可能とする動作安定化方法、動作安定化プログラム及び動作安定化装置を提供することを目的とする。
【課題を解決するための手段】
【０００９】
上記目的を達成するため本発明は、スマートフォンでアプリを連続稼働させる場面において、スマートフォンが予め本発明のスマートフォンの動作安定化方法を実行するための動作安定化プログラム（安定化ソフトウェア）を備えていることを想定している。安定化ソフトウェアによりアプリの正常な挙動を監視し、振る舞いがアプリ自身により規定された正常な挙動以外となった場合には、アプリを再起動することで安定的な連続稼働を実現する。
更に、安定化ソフトウェアは、スマートフォン自身の安定動作も定期監視し、スマートフォン自身の動作が不安定と判断される場合にも、スマートフォンの再起動を行って安定連続稼働を実現する。
【００１０】
すなわち請求項１のスマートフォンの動作安定化方法は、各種のアプリケーションが実行されるスマートフォンに格納された安定化ソフトウェアにより実行される方法であって、前記スマートフォンが実行する前記アプリケーションの挙動を監視する動作監視手順と、前記アプリケーションの挙動が予めアプリケーション自身により前記安定化ソフトウェアに登録された挙動と異なる場合には、当該アプリケーションの再起動を実施する再起動手順とを備えることで、前記アプリケーションの安定稼働を実現することを特徴としている。
【００１１】
請求項２は、請求項１のスマートフォンの動作安定化方法において、前記動作監視手順は、スマートフォンが実行するアプリケーションの挙動についてのログ情報を定期的にスマートフォン内の不揮発性保存領域に追記し、予め登録された前記アプリケーションの挙動についての情報と合致しているかを定期的に確認することで実行することを特徴としている。
【００１２】
請求項３は、請求項２のスマートフォンの動作安定化方法において、スマートフォンが実行するアプリケーションに対して、前記アプリケーション自身により予め登録された情報に記載のリクエストを送信し、アプリケーションにより登録された前記情報に記載の応答の有無を確認する応答監視手順を備え、応答がない場合には当該アプリケーションの再起動を実施することを特徴としている。
【００１３】
請求項４は、請求項３のスマートフォンの動作安定化方法において、前記安定化ソフトウェアは、前記安定化ソフトウェア自身とスマートフォンの状態を定期的に監視する機能を有し、異常を検知した場合に、前記安定化ソフトウェアまたはスマートフォンそのものの再起動を行う手順を備えたことを特徴としている。
【００１４】
請求項５は、請求項３のスマートフォンの動作安定化方法において、前記安定化ソフトウェアは、定期的にスマートフォンの状態を監視し、前記状態及び時刻情報から異常を検知した場合に、前記スマートフォンの再起動を行う手順を備えたことを特徴としている。
【００１５】
請求項６は、請求項５のスマートフォンの動作安定化方法において、スマートフォンの状態に関わらず、定期的にスマートフォン自体を再起動する手順を更に備えたことを特徴としている。
【００１６】
請求項７の動作安定化プログラムは、請求項１乃至請求項６のいずれか１項に記載の各手順をコンピュータに実行させることを特徴としている。
【００１７】
請求項８は、各種のアプリケーションが実行されるスマートフォンに安定化ソフトウェアを格納することで構築される動作安定化装置であって、次の構成を備えることを特徴としている。
前記アプリケーションに対して前記安定化ソフトウェアを利用するためのインタフェースを提供するアプリケーションインタフェース部。
前記アプリケーションについての起動中のアプリ情報を取得するアプリ動作監視部。
前記アプリケーションに対し定期的にリクエスト送信し、予め登録されたリクエストの応答内容と、前記アプリケーションからの応答内容を確認し、応答ない場合に該アプリケーションの再起動を実施するアプリ応答監視部。
定期的又はスマートフォンの電源オン／オフ検知時に、時刻情報とともに前記スマートフォンの状態（定期実行時／再起動検知時／バッテリー不足による停止検知時等）を保存領域に書き出すハートビート部。
前記安定化ソフトウェアに実装され、前記状態及び時刻情報から前記スマートフォンの異常を検知した場合に、前記アプリ動作監視部、アプリ応答監視部及びハートビート部を再起動するハートビート監視アプリ部。
【００１８】
請求項９は、請求項８の動作安定化装置において、スマートフォン自体を定期的に再起動する定期再起動部を備えたことを特徴としている。
【発明の効果】
【００１９】
本発明によれば、スマートフォンで実行する各種アプリについて、アプリの動作監視を行うことで、正常な挙動以外となった場合にアプリの再起動が行われる。
また、スマートフォンで実行する各種アプリについて、アプリからの応答を確認する応答監視を行うことで、アプリの安定動作を定期監視し、応答ない場合にアプリの再起動が行われる。
また、スマートフォン自身について、定期的に再起動が行われることで、各種アプリの動作の安定化が図られる。
【００２０】
その結果、アプリの安定連続稼働が可能となるので、遠隔の無人拠点のＮＷ監視や、小売流通業で利用されているＰＯＳ等、安定連続稼働を必要とするため現在専用の機器で実現されているサービスについて、スマートフォンで代替することができる。
【図面の簡単な説明】
【００２１】
【図１】本発明のスマートフォンの動作安定化方法を実施するためのプログラムをスマートフォン内に格納して構築された動作安定化装置のソフトウェアアーキテクチャ概要図である。
【図２】動作安定化装置のアプリケーションインタフェース部に入力するＸＭＬ情報の例である。
【図３】図２のＸＭＬ情報をグラフで表現したモデル図である。
【図４】Androidより取得したログの例（logcatの出力例）である。
【図５】動作安定化装置のアプリ動作監視部が作成するグラフ例を示すモデル図である。
【図６】アプリ動作監視部の処理手順を示すフローチャートである。
【図７】アプリ応答監視部の処理手順を示すフローチャートである。
【図８】ハートビート部が生成するスマートフォンの状態に関する情報のサンプル例である。
【図９】ハートビート部の処理手順を示すフローチャートである。
【発明を実施するための形態】
【００２２】
本発明のスマートフォンの動作安定化方法の実施形態の一例について、図１を参照しながら説明する。
スマートフォンには、各種機能を実現するための各種アプリケーションがインストールされ、本発明の動作安定化方法は各種アプリの安定動作を図るものである。
この動作安定化方法は、スマートフォンに動作安定化プログラム（安定化ソフトウェア）をインストールすることで、スマートフォン内に動作安定化装置１０およびハートビート監視アプリ部１５を構築し、スマートフォン自身で各種アプリの安定動作が実現できるように構成されている。動作安定化プログラム（安定化ソフトウェア）は、予めスマートフォンに組み込まれるものであってもよい。
なお、以後の記述において、具体的なログやシステムアーキテクチャを例示する場合は、現在最も普及しているAndroid OSの例を使用する。
【００２３】
動作安定化プログラム（安定化ソフトウェア）をインストールすることで構築される動作安定化装置に関するソフトウェアアーキテクチャ及びAndroidのシステムアーキテクチャを図１に示す。スマートフォンは、システムソフトウェアを構成するオペレーティングシステム１と、ユーザにアプリを提供するアプリケーション部２と、アプリそのものや各種設定、ログ情報等を記憶する記憶装置３を備え、アプリケーション部２には各種の機能を提供するアプリ（Ａ，Ｂ，Ｃ）が格納されている。
【００２４】
動作安定化装置１０は、各種アプリに対し安定化ソフトウェアの機能を利用するためのインタフェースを提供するアプリケーションインタフェース部１１と、起動中のアプリの情報を取得するアプリ動作監視部１２と、各種アプリに対し定期的にリクエスト送信しアプリからの応答の内容を確認するアプリ応答監視部１３と、時刻情報とともにスマートフォンの状態を保存領域に書き出すハートビート部１４と、安定化ソフトウェアの機能が動作しているかを安定化ソフトウェア自身により監視するハートビート監視アプリ部１５と、安定化ソフトウェアの機能の動作状況を管理者に通知するための通信インタフェース部１６と、スマートフォン自体を定期的に再起動する機能を有する定期再起動部１７の各機能部から構成されている。
【００２５】
以下、各機能部の動作内容について説明する。
・アプリケーションインタフェース部１１
安定化ソフトウェアの機能を利用する全てのアプリ（各種アプリ）は、アプリケーションインタフェース部１１を介して、安定化ソフトウェアの機能を実装したソフトウェアモジュールに各種アプリ自身の情報を登録する必要がある。登録情報には、正常動作時のアプリの振る舞いを規定した情報と、安定化ソフトウェアの機能が送信するリクエストの内容、アプリによるレスポンスの内容が含まれる。正常動作時のアプリの振る舞いを規定した情報とは、アプリ起動により、どのような処理と画面表示が実行され、正常動作であれば画面表示がどのように遷移するか、また各処理と画面表示のタイムアウト時間を示す。
正常動作時のアプリの振る舞いを規定した情報は、例えば拡張可能なＸＭＬ形式により記述され、安定化ソフトウェアの機能を利用する各種アプリの開発者は、当該ＸＭＬファイルをアプリのインストール時と起動時に、安定化ソフトウェアの機能を実装したソフトウェアモジュールに転送するようアプリを実装する。ＸＭＬファイルを受け取った安定化ソフトウェアは、ＸＭＬに記載の内容に基づき、アプリ動作監視部１２及びアプリ応答監視部１３の機能を実行する。アプリの情報は、ＸＭＬ情報の他に、テキスト形式等、ソフトウェアが読み込み可能な他の形式による情報であってもよい。
【００２６】
図２にＸＭＬ情報のサンプル、図３にＸＭＬ情報をグラフで表現したものを示す。
図２のＸＭＬ情報において、「Activity」は、フォアグラウンドで動作する１つの画面を意味し、「Service」は、バックグラウンドで動作する処理を意味する。
図２及び図３により、安定化ソフトウェアの機能を利用するアプリ「SAMPLE APPLICATION」はアプリ実行時に、「sample service１」２０と「sample activity１」２１を起動し、更に、「sample activity１」２１より「sample activity２」２２または「sample activity３」２３が実行されることが示される。Androidの仕様上、同時にフォアグラウンドで実行されるActivityは１つのみである。
【００２７】
また、各Service と Activity は、「hello」２５というリクエストメッセージに対し、「hello ack」２６という応答を返し、各レスポンスに対するタイムアウト２７とリトライ回数２８、Service や Activity のタイムアウト２４が確認できる。このタイムアウト２４以降において、Activity や Service が実行されている場合には異常と判断する。
【００２８】
・アプリ動作監視部１２
アプリ動作監視部１２は、スマートフォンのログの監視等により、現在起動中のService（群）や、フォアグラウンドになっているActivityの情報を取得する。起動中のService やActivity は、リストとして保存する。
図４にスマートフォンのログの取得結果（Android logcat 機能により取得）例を示す。図４には、Service や Activity が起動される様子（onCreate()ログ４１で起動)や、Activity およびService の切替り（Intent ログ４２で画面切替）が示される。
【００２９】
アプリ動作監視部１２の機能は、図４に示すログを監視し、特定の文字列から起動中のService やActivity、及びその遷移を示すIntent を時刻情報と共にグラフ化する（図５）。ログの監視では、Android の仕様上、Activity 及びService は、onCreate で始まり、onDestroy で終了するので、onCreate とonDestroy の文字列に注目してグラフが作成される。図５では、ログに記載されたプロセスＩＤで同一アプリであることを関連付けることで、アプリがどのように起動し、画面遷移したかについてが解かる。
【００３０】
アプリ動作監視部１２における処理フローを図６に示す。図６のフローチャートには、正常動作のシーケンスのみ記載する。
アプリ動作監視部１２は、経過時間測定のタイマー実行を行い（ステップ６１）、タイマー実行後に指定時間経過したかを判断する（ステップ６２）。
指定時間経過した場合、ログからAndroid 上でアプリがどのように動作（画面遷移）したかを示すグラフ（図５）を生成する（ステップ６３）。
次に、生成したグラフ（画面遷移）と、アプリにより予め登録された図３のグラフ（図２に示したアプリケーションインタフェース部１１のＸＭＬファイル情報）とを比較する（ステップ６４）。
【００３１】
この比較により、アプリが正しく遷移したか（アプリにより予め登録された遷移通りにAndroid 端末上で動作したか）、また、タイムアウト時間内に処理を完了したか（図５の各Service やActivity の起動時刻から、図２に例示したＸＭＬに記載のタイムアウト時間を超えていないか）を確認する（ステップ６５）。
確認の結果、アプリの異常な振る舞いを検知した場合には、アプリを再起動し、通信インタフェース１６を介してアプリの異常発生による再起動結果と共にログをサーバに通知する（ステップ６６）。
【００３２】
・アプリ応答監視部１３
アプリ応答監視部１３は、起動中のアプリに対してリクエストを送信し、それに対する応答を監視するものである。
アプリ応答監視部１３における処理フローを図７に示す。図７のフローチャートには、正常動作のシーケンスのみ記載する。
アプリ応答監視部１３は、経過時間測定のタイマー実行を行い（ステップ７１）、タイマー実行後に指定時間経過したかを判断する（ステップ７２）。
指定時間経過した場合、アプリ動作監視部１２においてログより作成した実行中のService とActivity のリストと、アプリより登録されたＸＭＬファイル（図２）より、起動中のアプリに対するリクエストを生成し、起動中のService（群）とActivity に対して、ＸＭＬファイルに記載のリクエストを送信する（ステップ７３）。
このリクエストに対して、ＸＭＬファイルに記載の応答が、タイムアウト時間内にあるかを確認する（ステップ７４）。
アプリからの応答が確認されない場合には、アプリを再起動し、通信インタフェース１６を介して再起動結果と共にログをサーバに通知する（ステップ７５）。
【００３３】
・ハートビート部１４
ハートビート部１４が生成し、不揮発性保存領域内に保存するスマートフォンの状態を示す情報サンプルの例を図８に示す。
図８には、日付及び時刻情報（YYYY-MM-DD-hh:mm:ss:sss）と、スマートフォンが定期実行時（ALIVE）／端末の再起動イベント検知時（REBOOT）／バッテリー残量低下による停止検知時（LOWBT）の３種類のうちいずれの状態であるかの情報が記載されている。
【００３４】
ハートビート部１４における処理フローを図９に示す。図９のフローチャートには、正常動作のシーケンスのみ記載する。
ハートビート部１４は、経過時間測定のタイマー実行を行い（ステップ９１）、タイマー実行後に指定時間経過したかを判断する（ステップ９２）。
次に、定期的または電源のオン／オフに関するＯＳイベントを検知した際に、スマートフォンの状態を示す前記した３種類の情報にタイムスタンプを付与し（ステップ９３）、端末内の不揮発性保存領域（ＳＤカード内等）に保存する（ステップ９４）。
【００３５】
・ハートビート監視アプリ部１５
安定化ソフトウェアは、ハートビート部１４の出力内容を監視する機能をハートビート監視アプリ部１５をアプリケーション部２に格納する。安定化ソフトウェアの動作は、ハートビート監視アプリ部１５により、定期的な監視が行われ、異常時には安定化ソフトウェア(ハートビート監視アプリ部を除く)の再起動が実施される。これにより、安定化ソフトウェアの正常動作を維持する。また、ハートビート監視アプリ部は、上記アプリ動作監視部１２およびアプリ応答監視部１３により正常動作を維持する。したがって、ハートビート監視アプリ部１５と、アプリ動作監視部１２、アプリ応答監視部１３、ハートビート部１４の各機能部が同時に異常停止しない限りは、再起動をしながらも動作を続ける。
【００３６】
すなわち、ハートビート監視アプリ部１５は、図８に記載のハートビート部１４が生成したスマートフォンの状態の情報（ハートビート）を定期的に監視し、時刻情報から本来定期的に記載されているはずのハートビートの異常を検知した場合には、安定化ソフトウェア(ハートビート監視アプリ部１５を除く)の再起動が実施されることで各機能部（図１の動作安定化装置１０内のアプリ動作監視部１２、アプリ応答監視部１３、ハートビート部１４の３つの処理部）を再起動する。
【００３７】
また、安定化ソフトウェア(ハートビート監視アプリ部１５を除く)の再起動後も、本来定期的なはずのハートビートの異常を再度検知した場合には、スマートフォン（端末）そのものが異常な状態にあると判断し、端末そのものを再起動する。再起動時には、通信インタフェース１６を介して再起動の結果をログと共にサーバに通知する。
【００３８】
また、スマートフォンの起動時に、ハートビートの内容を確認し、REBOOT（端末の再起動イベント検知時）やLOWBT（バッテリー残量低下による停止検知時）が最新のハートビートではない場合には、再起動のイベントが発生しない(本来安定化ソフトウェアが検知できるはずの電源再起動が検知できない)異常な形で再起動が発生した事を意味するため、通信インタフェース１６を介してシステムの管理者に原因不明の再起動発生としてサーバに通知する。
【００３９】
・通信インタフェース１６
通信インタフェース１６は、アプリ動作監視部１２やアプリ応答監視部１３、ハートビート監視アプリ部１５が、アプリや端末の再起動を実施した際に再起動結果とログをシステム管理者等に通知する。
【００４０】
・定期再起動部１７
定期再起動部１７は、スマートフォンを定期的に再起動する機能を有している。
【００４１】
スマートフォンやアプリの実行中に何らかの理由により陥る異常動作は、スマートフォン（端末）が無反応となるFreezes、端末が勝手に再起動するSelf-reboots、各種アプリが無反応となるHangs、各種アプリが突然終了するCrashes の４種類に分類される。
上述した動作安定化方法が実行された場合、各機能部により４種類の全ての異常状態を回避することができる。以下、４種類の異常状態の回避に各機能部がどのように寄与するかについて説明する。
【００４２】
現象Freezesに対しては、以下のように対処することができる。
ハートビート部１４において、ハートビートを定期的にサーバにアップロードすることで、ハートビートが一定時間内にサーバに到達しないことをもって、Freezes の発生を検知することができる。
ハートビート監視アプリ部１５において、ハートビートの間隔が異常な場合にスマートフォン（端末）を再起動することで、Freezes の発生を回避することができる。
定期再起動部１７において、定期的に再起動することでFreezes の発生を防ぐ。
【００４３】
現象Self-rebootsに対しては、以下のように対処することができる。
ハートビート部１４及びハートビート監視アプリ部１５において、ハートビートを確認することで、再起動の発生を検知することができる。また、ハートビート監視アプリ部１５が起動時のハートビートを確認することで、イベントが発生しない異常な再起動も検知することができる。
【００４４】
現象Hangsに対しては、以下のように対処することができる。
アプリ動作監視部１２において、Service やActivity 毎のタイムアウトを管理することで、Hangs の発生を検知することができる。検知した場合には各種アプリの再起動を実施する。
アプリ応答監視部１３において、起動中のアプリ(Service(群)とActivity)にリクエスト送信し、レスポンスの有無でHangs の発生を検知することができる。検知した場合には各種アプリの再起動を実施する。
【００４５】
現象Crashesに対しては、以下のように対処することができる。
アプリ動作監視部１２において、起動中の各種アプリを常時監視することで、Crashes の発生を検知することができる。検知した場合には各種アプリの再起動を実施する。
【００４６】
上述したスマートフォンの動作安定化方法及び動作安定化装置によれば、スマートフォン（端末）が無反応となるFreezes、端末が勝手に再起動するSelf-reboots、各種アプリが無反応となるHangs、各種アプリが突然終了するCrashes の４種類の異常動作の全てに対して、未然に防止するような動作が行われることで各種アプリの動作の安定化を図ることができる。
その結果、各種アプリの安定連続稼働が可能となるので、従来スマートフォンで実現することが困難であった遠隔監視等のサービスについて、スマートフォンで代替することができる。
【符号の説明】
【００４７】
１…オペレーティングシステム、  ２…アプリケーション部、  ３…記憶装置、  １０…動作安定化装置、  １１…アプリケーションインタフェース部、  １２…アプリ動作監視部、  １３…アプリ応答監視部、  １４…ハートビート部、  １５…ハートビート監視アプリ部、  １６…通信インタフェース、  １７…定期再起動部。
【図１】
0005729767.tif 000002
【図２】
0005729767.tif 000003
【図３】
0005729767.tif 000004
【図４】
0005729767.tif 000005
【図５】
0005729767.tif 000006
【図６】
0005729767.tif 000007
【図７】
0005729767.tif 000008
【図８】
0005729767.tif 000009
【図９】
0005729767.tif 000010