AndroidのFLAG_SECURE：スクリーンショットと画面録画をブロックする

AndroidのFLAG_SECUREがスクリーンショット、画面録画、最近使ったアプリのプレビューをどのようにブロックするかを、コード例、ユースケース、制限事項、キャスト時の挙動とともに解説します。

Bilal Harras 2025年12月29日

ときどき、まるで魔法のように感じられるAndroidのフラグに出くわすことがあります。FLAG_SECUREもその一つです。これを有効にすると、アプリは突然「スクリーンショットが撮れない」状態になります。いつものボタンの組み合わせが効かなくなり、画面録画は不思議なことに真っ黒になり、UIは最近使ったアプリのプレビューから消えてしまいます。まるで強力なDRMのスイッチのように見えます。

実際はそうではありません。内部的には、FLAG_SECUREはとてもシンプルなものです。Androidに対して「この特定のウィンドウは機密性が高いので、そのピクセルをキャプチャさせないでほしい」と伝える手段にすぎません。それだけです。暗号化も秘密のハンドシェイクもなく、誰かが画面の内容を取得しようとしたときに、そのウィンドウをどう扱うべきかをシステムに強く示すだけです。

本記事では、FLAG_SECUREが実際に何をするのか、概念的にどう動作するのか、コードでどう使うのか、どこで有効にするのが理にかなっているのか、ユーザーを煩わせずに使うためのパターン、そして決して無視してはならない制限事項を順に見ていきます。

1. `FLAG_SECURE`が実際に行うこと

まずは、このフラグが有効なときに人々が実際に何を目にするのかから始めましょう。たいていの疑問はそこから生まれるからです。

ウィンドウ（たとえばActivity）にFLAG_SECUREを設定すると、Androidはそのウィンドウをキャプチャ可能な通常のUIとして扱うのをやめ、ピクセルを求めるあらゆるものに対して「手出し禁止」の印を付けます。

最初に気づく副作用は、スクリーンショットがブロックされることです。セキュアなウィンドウが前面にある間は、いつものシステムのショートカット（たとえば電源 + 音量下）でスクリーンショットが撮れないか、完全に黒い、あるいは何も写っていない画像が生成されます。ユーザーから見ると、端末がその画面のスクリーンショットを撮らないように見えるだけです。その裏では、Androidが忠実にルールに従っています。ウィンドウがセキュアとしてマークされているので、ピクセルが外に出ないのです。

止められるのは標準のスクリーンショット機能だけではありません。サードパーティのスクリーンショットアプリの多くも同じ状況に置かれます。これらのアプリも画面の内容をキャプチャするためにシステムレベルの仕組みに依存しており、セキュアなウィンドウに属するピクセルを要求すると、プラットフォームからは何も渡されません。結果は通常同じで、黒い画像や何も写っていない画像になるか、そもそもキャプチャに失敗します。ただし、別のカメラで画面を撮影することは依然として可能である点に注意してください。

画面録画についても状況は同様です。画面録画アプリでは通常、セキュアなウィンドウが表示されている場所に、アプリのコンテンツではなく黒い領域が表示されます。動画自体は得られますが、セキュアなウィンドウがフレーム内に現れる箇所はすべて暗い長方形になります。録画アプリによっては、周囲のシステムUIやセキュアでない他のウィンドウが映ることもありますが、自社のウィンドウは隠されたままです。機密性の高いコンテンツがある場所だけ、録画に穴を開けるようなものです。

さらに、最近使ったアプリ／概要画面があります。上にスワイプしたり、［最近］ボタンをタップしたりしたときに表示される画面です。通常、AndroidはアプリのUIのスナップショットを撮り、それを小さなカードのプレビューとして使用します。FLAG_SECUREが有効な場合、そのスナップショットは意図的に役に立たないものになります。システムの概要画面／最近使ったアプリ画面では、Androidはセキュアなウィンドウの画像を表示しません。通常は単色または黒い長方形として表示され、アプリがバックグラウンドにあるときや、誰かが肩越しに開いているアプリを次々に切り替えているときに、機密情報が見えないようにします。

そして、これらはすべて非常に意図的にスコープが限定されています。FLAG_SECUREは端末全体をロックするわけでも、すべてのアプリに影響するわけでもありません。設定された特定のウィンドウ（Activity、Dialogなど）にのみ適用されます。別のActivityにフラグを設定しなければ、その画面は通常どおりに動作します。スクリーンショットも録画もでき、最近使ったアプリのプレビューにもUIがそのまま表示されます。

要するに、FLAG_SECUREは、ユーザー（または他のアプリ）がAndroid自身の表示パイプラインを通じてアプリから視覚的にキャプチャできるものを保護しますが、それはグローバルな「プライバシーモード」としてではなく、ウィンドウ単位で行われます。

セキュリティポリシーによる「スクリーンショットがブロックされました」という警告を表示したスマートフォン画面のクローズアップ。Android開発で画面キャプチャを防ぐためにFLAG_SECUREウィンドウフラグを有効にした結果を示している — AndroidのFLAG_SECUREの例：スクリーンショットのブロック通知

2. `FLAG_SECURE`の内部的な仕組み

目に見える挙動を確認したところで、概念的に実際に何が起きているのかを見ていきましょう。

このフラグは、ウィンドウに付いたプライバシースイッチとして考えるのが最も簡単です。

スイッチON → Androidに「このウィンドウのピクセルを、キャプチャ可能な形でセキュアな表示パイプラインの外に決して出さないこと」と伝えます。
スイッチOFF → ウィンドウは通常のものとして振る舞い、スクリーンショットも録画も許可されます。

内部的には、ウィンドウにFLAG_SECUREが設定されていると、Androidのコンポジターはそのウィンドウが「セキュア」であることを記録しておきます。スクリーンショットAPI、画面録画、最近のタスクのサムネイル生成、あるいは一部のキャスト／ミラーリングのシナリオなど、システムが画面のキャプチャを求められるたびに、表示されているすべてのウィンドウから画像を組み立てる必要があります。セキュアでないウィンドウについては、そのピクセルをそのままキャプチャにコピーします。セキュアなウィンドウについては、画面をキャプチャしようとすると、そのウィンドウが除外されるか、黒い／何もないプレースホルダーに置き換えられます。

重要なのは、これがアプリのロジックではなくシステムによって強制されるという点です。スクリーンショットのイベントを横取りしたり、録画アプリが動いているかどうかを推測したりする必要はありません。フラグが設定されれば、そのウィンドウのピクセルがスクリーンショット、録画、サムネイルに漏れないようにする責任はAndroid自身が負います。公式のAPIを使って巧妙に画面をキャプチャしようとする他のアプリも、同じルールに縛られます。ピクセルを要求しても、コンポジターがセキュアポリシーを適用するため、コンテンツは表示されません。

これが、ソフトウェアを介してUIをキャプチャしようとする何気ない試みや、ある程度執拗な試みに対しても、FLAG_SECUREがそれなりに堅牢である理由でもあります。しかし、これがカバーしない範囲を心に留めておくことが極めて重要です。このフラグが制御するのは、Androidのレンダリングパイプラインを通じた視覚的なキャプチャだけです。ストレージ、ネットワーク、その他のどこにあるデータも、魔法のように保護してくれるわけではありません。

3. コードで`FLAG_SECURE`を使う方法

実装の部分は簡単です。秘密のAPIも特別な権限も必要なく、ウィンドウにフラグを設定するだけです。

通常は、ActivityのonCreateの中で、setContentViewを呼び出す前かその前後に有効にします。Javaでは次のようになります。

JavaでFLAG_SECUREを使う方法：

import android.os.Bundle;
import android.view.WindowManager;
import androidx.appcompat.app.AppCompatActivity;

public class SecureActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        getWindow().setFlags(
            WindowManager.LayoutParams.FLAG_SECURE,
            WindowManager.LayoutParams.FLAG_SECURE
        );

        setContentView(R.layout.activity_secure);
    }
}

KotlinでFLAG_SECUREを使う方法：

import android.os.Bundle
import android.view.WindowManager
import androidx.appcompat.app.AppCompatActivity

class SecureActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        window.setFlags(
            WindowManager.LayoutParams.FLAG_SECURE,
            WindowManager.LayoutParams.FLAG_SECURE
        )

        setContentView(R.layout.activity_secure)
    }
}

これだけで、そのActivityのウィンドウは、Activityが存在している間ずっとセキュアになります。

ただし、ウィンドウを常にセキュアにしたいとは限りません。画面の一部だけが機密で残りはそうでない場合や、スクリーンショットを許可したい特定のモードがある場合もあるでしょう。そのような場合は、不要になった時点で実行時にFLAG_SECUREを解除できます。

Kotlinで、不要になったFLAG_SECUREを実行時に解除する方法：

window.clearFlags(WindowManager.LayoutParams.FLAG_SECURE)

Javaで、不要になったFLAG_SECUREを実行時に解除する方法：

getWindow().clearFlags(WindowManager.LayoutParams.FLAG_SECURE);

ここで重要なのは、FLAG_SECUREがアプリ単位ではなくウィンドウ単位であるという点です。定数は次のとおりです。

WindowManager.LayoutParams.FLAG_SECURE

これをアプリ全体に自動的に適用するマニフェストの設定はありません。ウィンドウごとに設定（または解除）する必要があります。

保護したい各Activity
セキュアにすべき各Dialogまたはカスタムウィンドウ

これは機能であると同時に、自分の足を撃ちかねない落とし穴でもあります。きめ細かな制御ができる一方で、機密性の高い画面をすべて漏れなくカバーしていることを自分で確認しなければなりません。

4. `FLAG_SECURE`の一般的なユースケース

では、現実の世界ではどこでこれを使うのが理にかなっているのでしょうか。手短に答えるなら、誰かのスクリーンショットのアーカイブ、クラウドバックアップ、チャット履歴に何気なく残ってほしくない情報を表示する場所すべてです。

よくあるカテゴリをいくつか見ていきましょう。

4.1 銀行・金融アプリケーション

銀行・金融アプリは、まさにその代表例です。口座残高、取引明細書、取引履歴、カード番号、ワンタイムパスワード（OTP）を表示する画面には、機密性が高く、悪意のある人の手に渡れば再利用されやすいデータが詰まっています。これらの画面でスクリーンショットが自由に撮れてしまうと、その情報はユーザーの写真ギャラリーに保存されたり、クラウドストレージに同期されたり、メッセージアプリで転送されたりします。しかも多くの場合、暗号化もアクセス制御も一切ありません。

こうした金融関連の画面でFLAG_SECUREを有効にすることは、その漏えい経路の手前に基本的な減速帯を設けることになります。別の端末で画面を撮影しようと決めている人を止めることはできませんが、「ちょっとスクリーンショットを撮っておこう」という何気ない行動の多くを防ぐことができます。そうした行動こそ、後になって人々を悩ませるものです。

個人を特定できる情報（PII）や金融資産など、極めて機密性の高い情報を表示するフィンテックアプリケーションのイラスト。データ漏えいや不正アクセスに対する堅牢な防御を必要とする重要なアタックサーフェスを表している。

4.2 認証・セキュリティアプリケーション

パスワードマネージャー、2FA／OTPジェネレーター、本人確認フローなど、認証やシークレットに関わるものを構築しているなら、FLAG_SECUREをしっかりと視野に入れておくべきです。

こうしたアプリは、パスワード、リカバリーキー、バックアップコード、有効期間の短いログインコードなど、価値の高いシークレットを日常的に表示します。ユーザーがこれらの画面のスクリーンショットを撮れると、それらはまさに保存してほしくない場所、つまりカメラロール、クラウドのギャラリー、適当なメモアプリに保存されがちです。そこから先へ漏えいするのに、たいした手間はかかりません。

シークレットを表示するアプリの部分にFLAG_SECUREを適用すれば、OSを介して簡単にキャプチャされることはなくなります。ユーザーがそれらを残しておきたい場合は、書き留める、別のカメラを使うといった、より意図的な手順を踏む必要があります。これですべての問題が解決するわけではありませんが、あらゆる場所でスクリーンショットが許可されているときに見られる偶発的な露出を劇的に減らせます。

時間ベースのワンタイムパスワード（TOTP）とセキュリティトークンを生成する多要素認証（MFA）ユーティリティのイラスト。視覚的な情報収集の手法から保護しなければならない重要なシークレットの取り扱いを示している。

4.3 ヘルスケア・医療アプリケーション

ヘルスケア・医療アプリは、データが極めて個人的なものであり、多くの法域で厳しく規制されているという特別なカテゴリに属します。

個人の健康記録、臨床検査の結果、診断、治療の詳細、詳細な診察メモを表示する画面は、「ちょっとしたプライベート情報」ではありません。多くの場合、厳格なプライバシー法の対象となります。これらの画面をスクリーンショットや動画としてキャプチャでき、それが自動的にバックアップされたり共有されたりするのであれば、非常に機密性の高いデータがアプリの管理下から出ていく容易な経路を作ってしまったことになります。

これらの画面でFLAG_SECUREを使うことは、そのリスクの低減に役立ちます。適切な暗号化、アクセス制御、コンプライアンス対応の代わりにはなりませんが、非常に具体的な問題に対処できます。それは、人々が自分の検査結果をさっとスクリーンショットに撮り、医療プライバシーを前提に設計されていない環境へ、知らないうちにその画像を送り込んでしまうという問題です。

電子健康記録（EHR）と保護対象保健情報（PHI）を表示するヘルスケアモバイルアプリケーションのイラスト。厳格な規制コンプライアンス（HIPAAなど）の対象となり、データの露出に対する強力な制御が求められるインターフェースを示している。

4.4 エンタープライズ・社内ツール

組織の内部には、誰もTwitterに載ってほしくないような、あらゆる種類の情報を露出する社内ダッシュボード、管理パネル、デバッグツールがよくあります。社内の指標、顧客データ、インシデントのタイムライン、設定画面、識別子やシークレットが散在するログ画面などを思い浮かべてください。

こうした環境では、従業員がスクリーンショットを撮って社内で共有することはごく普通のことかもしれません。しかしそれも、そのスクリーンショットの一枚が組織の外へ漏えいしたり、決してあってはならない場所に現れたりするまでの話です。本番システムに対して使われるデバッグツールは特に危険です。そもそも顧客に見せることを想定していない生データを表示することが多いからです。

特に機密性の高い管理画面や社内ツールでFLAG_SECUREを有効にすることは、そうした行動による被害範囲を限定する現実的な方法です。作業内容を記録することは引き続き可能ですが、最も機密性の高い社内UIを、ピクセル単位で正確に複製して配布することはもはや容易ではなくなります。

運用インテリジェンス、システムアラート、ユーザーログを露出する社内管理コンソールのイラスト。特権アクセス管理とデータマスキングを必要とする、見落とされがちな攻撃ベクトルを浮き彫りにしている。

4.5 プライバシーが重要なコミュニケーションとキオスクのシナリオ

特定の分野よりも、人々がアプリをどのように使うかによって機密性が決まる種類のアプリもあります。セキュアメッセージング、一時的なチャット、自動消滅するメッセージなどがよい例です。

「このメッセージは消えます」とうたっているのに、UIが簡単にスクリーンショットに撮れるのであれば、体験と期待が食い違っています。誰かが別のスマートフォンを画面に向けるのを止めることはできませんが、少なくとも、簡単に使える標準のキャプチャ経路を認めないようにすることはできます。そうした特別な会話にFLAG_SECUREを付けることは、これは写真ギャラリーに永遠に残すためのものではない、という明確なシグナルを送ることになります。

キオスク型のアプリケーションも興味深いケースです。チェックイン端末、順番待ちシステム、セルフサービスのフォームなど、半公共の場所で人々が近づいて使う共有端末を考えてみてください。こうした画面には、氏名、ID、予約の詳細、その他の個人データが短時間表示されることがよくあります。これらのフローでFLAG_SECUREを有効にすれば、機会をうかがうユーザーや、端末上で動作する悪意のあるソフトウェアが、画面に表示された内容をひそかに収集することをはるかに困難にできます。

一時的なデータ（消えるメッセージ）とセキュアな通信を示すインジケーターを備えたセキュアメッセージングプラットフォームのイラスト。パステルレッドの背景により、スクリーンショット防止のようなアンチフォレンジックのセキュリティポリシーが積極的に適用されていることを強調している。

これらすべてのカテゴリに共通する原則は、画面に表示される内容の機密性が、スクリーンショットの利便性を明らかに上回る場所でFLAG_SECUREを使うということです。それ以外の場所では、有効にする前によく考えてください。

5. 設計パターン：どこで、いつ有効にするか

アプリのあちこちにFLAG_SECUREを無作為にちりばめるのは戦略とは言えません。セキュリティとユーザビリティのバランスを取る、意図的なパターンが必要です。

シンプルなパターンの一つが、「常にセキュア」なActivityです。画面によっては、表示するものすべてが機密です。典型的な例はOtpVerificationActivityやCardDetailsActivityのようなものです。こうした画面では、onCreateでFLAG_SECUREを設定し、一度も解除しないだけで済みます。ユーザーがそのActivityに来たときはいつでも、スクリーンショットも録画も完全に不可能です。

よりきめ細かなパターンが、状態に基づく切り替えです。通常は無害なコンテンツを表示しているものの、ときどき「機密情報の詳細」パネル、たとえば口座番号の全桁を表示するボトムシートを表示する、単一のMainActivityを想像してください。そのパネルが非表示の間は、スクリーンショットをブロックする理由はありません。パネルを表示した瞬間にフラグをオンにし、閉じられたらフラグを再びオフにします。Kotlinでは次のようになります。

fun showSensitiveContent() {
    window.setFlags(
        WindowManager.LayoutParams.FLAG_SECURE,
        WindowManager.LayoutParams.FLAG_SECURE
    )
    // Show a fragment or view containing sensitive data
}

fun hideSensitiveContent() {
    window.clearFlags(WindowManager.LayoutParams.FLAG_SECURE)
    // Hide that fragment or view
}

このパターンなら両方の利点が得られます。一般的なUIのスクリーンショットは引き続き撮れる一方で、本当に機密性の高い場面は保護されます。

さらに、ダイアログのみをセキュアにするというアプローチもあります。フロー全体の中で機密性の高い部分が、一時的なダイアログだけという場合もあります。たとえば、カード番号の全桁、リカバリーフレーズ、ワンタイムのシークレットを表示するポップアップです。こうした場合は、Activity全体ではなく、ダイアログ自身のウィンドウにFLAG_SECUREを設定するのが理にかなっていることがあります。ベースの画面はスクリーンショットを撮れるまま、ダイアログの内容はキャプチャに決して写りません。

どのパターンを選ぶにしても、重要なのは一貫性です。どの画面や状態を機密とみなすかを定義し、そこにFLAG_SECUREを適用し、それ以外には手を付けないことです。そうすれば、ユーザーを無作為に驚かせることもなく、リスク低減の効果が最も大きい場所に的を絞ってフラグを適用できます。

6. 制限事項と誤解

ここからは、機能と同じくらい重要な部分、つまりFLAG_SECUREがしないことについてです。

最も大きいのは、カメラや外部デバイスはブロックしないという点です。ユーザーは別のスマートフォン、デジタル一眼レフ、Webカメラなど、好きなものを画面に向けてキャプチャできます。FLAG_SECUREが制御するのは、Androidの内部でのソフトウェアによるキャプチャだけです。脅威モデルに、誰かがその場に立って端末を物理的に撮影するケースが含まれているなら、このフラグは役に立ちません。

次に、FLAG_SECUREはデータを暗号化したり、その他の方法で保護したりはしません。保護するのは画面の表示であり、次のものは保護しません。

ネットワーク通信
ディスク上のストレージ
ログ、キャッシュ、バックアップ

機密データをネットワーク経由で送信するなら、依然としてHTTPSが必要です（そして証明書を正しく検証する必要もあります）。シークレットをディスクに保存するなら、暗号化されたデータベースやEncryptedSharedPreferencesのような暗号化の仕組みが依然として必要です。機密性の高い値をログに記録しているなら、それらのログが中央のサーバーに送られたときにFLAG_SECUREは助けてくれません。

スコープの問題もあります。このフラグはグローバルではなくウィンドウ単位なので、ある経路を保護して別の経路を忘れることが非常に起こりやすいのです。機密データが、FLAG_SECUREを設定していない別のActivityやビューからも表示できるなら、その画面は依然としてキャプチャできます。「この一つの画面」ではなく、「この情報が表示されるすべての場所」という観点で考える必要があります。

もう一つの微妙な点は、FLAG_SECUREは過去のキャプチャをさかのぼって保護するわけではないということです。フラグを有効にする前に撮られたスクリーンショットや録画には影響しません。それらは、ローカルのギャラリー、クラウドバックアップ、メッセージアプリなど、ユーザーが保存した場所にそのまま残ります。フラグが適用されるのは、フラグが有効な間のキャプチャの試みだけです。

最後に、ユーザー体験とのトレードオフがあります。バグの報告、手順の保存、ワークフローの記録にスクリーンショットを多用するユーザーもいます。ユーザーが特に機密だと感じていない場所でスクリーンショットをブロックすれば、彼らを苛立たせることになります。FLAG_SECUREを使いすぎると、特にスクリーンショットが許可されない理由を明確に伝えていない場合、アプリが不必要に締め付けられているとユーザーに感じさせるおそれがあります。

要点をまとめると、FLAG_SECUREは特定の一つの問題に非常にうまく対処する、焦点を絞ったツールです。銀の弾丸ではありません。その周りには、依然として本格的なセキュリティ設計が必要です。

7. キャストや外部ディスプレイとの相互作用

最後に、多くの人を驚かせる注意点があります。画面をキャストやミラーリングしているときのFLAG_SECUREの挙動です。

Androidのバージョンや端末によっては、FLAG_SECUREが付いたコンテンツが、特定の外部ディスプレイにはまったく表示されないことがあります。システムが外部ディスプレイを「セキュアでない」とみなす場合（たとえば、一部のキャスト先やミラーリングされたディスプレイ）、スクリーンショットや録画の場合と本質的に同じロジックが適用されます。

実際には、画面のミラーリングやキャストのセッション中に次のようなことが起こります。

セキュアなウィンドウが、リモートのディスプレイ上で何もない領域や黒い領域として表示されることがある。
セキュアでないUIやシステムのクロームは、引き続き表示されることがある。
セキュアなウィンドウが前面にあるときは常に、キャストされた出力上でアプリのUIの一部が「欠けている」ように見えることがある。

この挙動は、ドキュメントでときどき目にする「ウィンドウのコンテンツがスクリーンショットに写ったり、セキュアでないディスプレイで表示されたりするのを防ぐ」という記述と一致しています。ここでいう「セキュアでないディスプレイ」とは、端末のメイン画面で保証できるのと同じ保証を強制できるとAndroidが完全には信頼していない出力先を簡潔に表したものです。

アプリがプレゼンテーション、デモ、リモートサポートのシナリオで多く使われるのであれば、セキュアな画面がキャスト時にどう振る舞うかをテストし、それが許容できるかどうかを判断する価値があります。場合によっては、そうした状況向けの代替フローや、少なくとも画面を共有できない理由を説明するわかりやすいメッセージが必要になるかもしれません。

8. まとめ

FLAG_SECURE（WindowManager.LayoutParams.FLAG_SECURE）は、「このウィンドウのピクセルをキャプチャさせない」ことを示すAndroidのウィンドウフラグです。ウィンドウに設定すると、標準のスクリーンショットが機能しなくなり、そのウィンドウが表示される場所は画面録画で黒くなり、最近使ったアプリの画面では意味のあるサムネイルが隠され、さらに特定の外部ディスプレイにコンテンツが表示されないようにすることもできます。

使い方は、重要なウィンドウ、通常は特定のActivityやDialogにフラグを設定し、必要であれば、UIが機密データを表示しなくなった時点で再び解除するというものです。

window.setFlags(
    WindowManager.LayoutParams.FLAG_SECURE,
    WindowManager.LayoutParams.FLAG_SECURE
)

// Later, if needed:
window.clearFlags(WindowManager.LayoutParams.FLAG_SECURE)

銀行の詳細情報、認証用のシークレット、健康データ、社内ダッシュボード、プライバシーが重要なチャット、キオスクのフローなど、本当に機密性の高い情報や規制対象の情報を表示する画面では、これを検討すべきです。ただし、これがしないことについても明確に理解しておく必要があります。カメラは止められず、何も暗号化せず、自分でそうしない限りグローバルには適用されず、過去のスクリーンショットも消去しません。

よく考えて使えば、FLAG_SECUREは、スクリーンショットや画面録画を介してピクセルがアプリの外に出ていくという、特定の、しかも非常によくある漏えいを塞ぐのにとても便利な方法です。これはAndroidのセキュリティのすべてではありません。しかし、適切な画面においては、ぜひとも取り入れるべき対策です。

タグ：

android, security, mobile