20190403のAndroidに関する記事は5件です。

Dagger2を使ったアプリでfragment-testingを使ってみたら"No injector was found..." エラー

はじめに

https://developer.android.com/training/basics/fragments/testing

AndroidX TestでJVM上でEspressoのテストが実行可能になり、さらにfragment-testing を使えば以下のように簡単にFragment単体でのUIテストを実行できます。

@Test
fun test() {
    launchFragmentInContainer<FooFragment>()
    ...
    onView(...).check(...)
}

しかし、Dagger2を使った既存のアプリで fragment-testing を試してみたところ、以下のようなエラーが発生しました。

java.lang.IllegalArgumentException: No injector was found for FooFragment

Injectorが見つからないとのこと。。。

原因

launchFragmentInContainer() の内部実装を見てみるとテスト用の空Activityである EmptyFragmentActivityにテスト対象のFragmentをattachしていることがわかります。
そしてEmptyFragmentActivity は単純なFragmentActivityを継承したクラスで、Dagger2のHasSupportFragmentInjector は実装していません。
私の試した環境ではHasSupportFragmentInjector未実装ActivityにattachされたFragmentのFragment#onAttach() 内で AndroidSupportInjection#inject(fragment)を呼び出してしまったことが原因で上記エラーが発生してしまいました。

対処法

launchFragmentInContainer() では起動するActivityを任意のものに差し替えることは(今のところ)できません。
https://issuetracker.google.com/issues/121347222

ではどうするか。。。

ApplicationクラスでHasSupportFragmentInjector を実装しましょう!
Applicationクラスで実装しておけばActivityクラスでHasSupportFragmentInjector を実装する必要はありません。

class TestApp: DaggerApplication(), HasSupportFragmentInjector {
    @Inject
    lateinit var supportFragmentInjector: DispatchingAndroidInjector<Fragment>

    override fun supportFragmentInjector(): DispatchingAndroidInjector<Fragment> = 
        supportFragmentInjector

    ...
}

これでlaunchFragmentInContainer() でFragmentを起動可能になり、無事にテスト実行可能になります :sparkles:

サンプルコード

https://github.com/atsuya046/FragmentTest

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Android ChromeでPull-to-RefreshをCSSで無効化する。

はじめに

Pull-to-Refresh(ページの一番上までいる時にさらに下にスワイプするとリロードされるやつ)
を無効にしたいと思い調べた所、JavaScriptつかってごにょごにょすれば出来る記事はあったのですが、
最近はCSSだけでいけるようなので試してみました。

対象プロパティ

設定例

body {
  overscroll-behavior-y: none;
}

各ブラウザの対応

  • Android Chrome は63以降(2017/12リリース)
  • iOS Safari は未対応 なので普通に使われてるAndroidであればたぶん大丈夫。

https://developer.mozilla.org/ja/docs/Web/CSS/overscroll-behavior-y#Browser_compatibility

まとめ

PWA対応時の際にはPull-to-Refreshが邪魔になる事があるのでさくっと無効にできるのは便利です。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[和訳&抜粋]Android Security & Privacy 2018 Year in Review

記事概要

この記事は
Android Security & Privacy 2018 Year in ReviewOverviewのみを抜粋して和訳したものです。
残りは後日記載予定です。
一次情報はリンク元をご確認ください。

Android Security & Privacy 2018 Year In Review / March 2019

Overview

この5年目のレビューは、Androidの10周年にあたるという点で非常に特別です。
Dianne Hackbornの『Celebrating a Sweet Decade of Android』にそれが述べられています。

10年前、T-Mobile G1を搭載したAndroidオペレーティングシステムの最初のバージョンを発表し、そして同じ日にAndroid Market(現在はGoogle Play)を立ち上げました。それ以来、Androidは大きく成長してきました。現在世界中で20億以上のアクティブなAndroidデバイスがあります。

リリースされるすべての新しいAndroidバージョンには、新機能、改善点、およびセキュリティ強化が含まれています。このレポートで説明したデータは、Androidがすべてのメジャーバージョンでより安全になることを示しています。主なセキュリティ機能強化はsource.android.comEnhancements sectionに記載されています。

Our Strategy

Androidセキュリティチームの使命は、20億人以上のAndroidユーザーを保護することです。
私達はプライバシーを守るための技術に大規模な投資や継続的な改善を行いこれを実行します。
私たちの戦略は次の3つの柱に分けられます。

Layered Security

保護には階層的なアプローチを適用します。
Androidセキュリティモデルの各層は連携して、円滑かつ効果的に機能する強力な防御を構築します。
Androidセキュリティの主な層は次のとおりです。
- オペレーティングシステムの防御 (Operating system defense)
- アプリの安全防衛 (App safety defense)
- ヒューマンリサーチと分析 (Human research and analysis)
- セキュリティ開発のライフサイクル (Security development lifecycle)

Transparency

透明性と開放性は、Androidの基盤です。
透明性が信頼を生み出す一方で、閉鎖的なプラットフォームは不信感を招いて不信感と危険な誤った安心感をもたらします。
Androidの透明性は、オペレーティングシステム自体がオープンソースであるという性質をはるかに超えています。
私たちのチームは、脅威の調査、新機能に関するブログの定期的な発行、およびセキュリティ修正プログラムの毎月の総合的なセキュリティ情報を配布しています。 また、最近は四半期ごとに更新されるAndroidエコシステムの透明性レポートを開始しました。また、ブログ、ビデオ、レポートに簡単にアクセスできるように、最近更新されたAndroid Security Center Webサイトで無数の情報を公開しています。

Backed by Google

AndroidはGoogleに支援されています。つまり、当社のセキュリティチームは、ID管理、人工知能、プライバシー調査、クラウドセキュリティに関する世界クラスの専門知識を駆使して、業界で最も優れたセキュリティおよびコンピュータサイエンスの専門家と協力していることを意味します。

The best of Android Security & Privacy in 2018

デバイスの衛生状態を測定するための俯瞰的な統計は、デバイス全体をスキャンし、潜在的に有害なアプリケーション(PHA)が検出される割合です。
Androidに内蔵されている防御メカニズムであるGoogle Play Protectは、PHAをGoogle Playから排除するのに非常に効果的ですが、それでも悪意のあるアプリは他のソース(アプリストア)からダウンロードすることができます。
これらのアプリはデバイスだけでなく、Androidの周辺環境の尊厳も脅かされます。
これが、Google Play Protectがソース(アプリストア)に関係なくデバイスにインストールされているすべてのアプリをスキャンする理由です。

2018年には、アプリのダウンロードにGoogle Playのみを使用していたデバイスの0.08%がPHAの影響を受けていました。
これとは対照的に、Google Play以外からアプリをインストールしたデバイスは、PHAの影響を8倍以上頻繁に受けていました。
前年と比較して、Google Play Protectの警戒により、これらのデバイスでもマルウェアが15%減少しています。

Androidのセキュリティ機能において、2018年にアプリケーションサンドボックスが強化されました。そしてBiometricPromptなどの機能を備えた開発者向けAPIと、ターゲットAPI levelが更新されています。
Androidセキュリティチームは、Protected ConfirmationStrongboxなどの業界初のセキュリティAPIの使用を可能にする個別の改ざん防止された安全な要素を通じて、ハードウェアによるセキュリティへの投資を継続しています。

2018年に、報酬プログラムの総額支払い額は300万ドルを超えました。

私たちのAndroidセキュリティ報酬プログラムは、私たちがAndroidエコシステムのセキュリティを向上させるために世界中からトップの研究者と協力することを可能にします。 これらのプログラムは業界で最も高額な報酬を提供します。

Trebleのようなプラットフォーム改善の組み合わせを通して、
新しい相手先商標製造会社(OEM)契約、
Android Enterprise Recommendedなどのパートナープログラムや、Androidエコシステムは、セキュリティアップデートのリリースにおいて大きな進歩を遂げました。

2018年第4四半期に、セキュリティ更新プログラムを受信したデバイスが前年同期比で84%増えました。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Boost を Android 向けに bjam ビルドするテクニック(NDK r19c or later)

背景

  • Boost をどうしても利用しないといけない状況にある(使いたいライブラリが Boost を使っていて, コードを書き換えるにはめんどいなど)
  • Boost の機能全部を利用するわけではない
  • Android だと NDK の関係でコンパイラ指定が変わるので(r19 から standalone_toolchain.py でコンパイラのセットアップは deprecated になり, コンパイラの直指定に変わった), 明示的にコンパイラ設定をしたい
  • 本当は cmake でのビルドにしたいが, bcm https://github.com/boost-cmake/bcm などがあるが, 理想は boost を submodule としてビルドしたいので, bcm は求めているのと違う感じもするのでとりあえず bjam/b2 でビルドする

対象

  • NDK r19c or later
  • Boost 1.69.0

ネットでは古い NDK を対象にする記事が多いので, ここでは NDK r19c or later(clang 限定 + standard_toolchain ではなく, aarch64-linux-android28-clang++ のようにコンパイラを直指定のバージョン)を扱います.

ちなみに gcc は NDK18 あたりで廃止され, clang のみ(+ libc++)になりました.

BCP

まず, boost 全部を使う必要はないので, bcp で必要なモジュールだけ抜き出します.
(bjam で --without-*** という手もがあるがめんどい)

https://www.boost.org/doc/libs/1_69_0/tools/bcp/doc/html/index.html

bcp では, 使いたい機能(+ file?)を指定すると, 指定したターゲットのディレクトリに一式よろしくファイルをコピーします

$ bcp <<packages>> /path/to/target

ライブラリのコンパイルが不要(header file だけで完結)の場合はここで終了です.
お疲れさまでした. :relaxed:

ライブラリのコンパイルが必要なもの(e.g. system, thread)では,

build bootstrap.bat bootstrap.sh boostcpp.jam boost-build.jam

を bcp の <<packages>> に含めておきます.

ビルドカスタム設定

user-config.jam で, コンパイラ指定をします.
$NDK_ROOT/toolchains/llvm/prebuilt/linux-x86_64/bin にコンパイラがあります.

# Set path to toolchain
local AndroidToolchainRoot =
/home/syoyo/local/android-ndk-r19c/toolchains/llvm/prebuilt/linux-x86_64
;

using clang
: android
: $(AndroidToolchainRoot)/bin/aarch64-linux-android28-clang++
;

など.

b2--user-config オプションでファイルのありかを指定し, toolset=clang とすることで, user-config.jamusing clang の設定を見るようになります.

$ ./configure
$ ./b2 --reconfigure toolset=clang target-os=android link=static --user-config=user-config.jam

などとしてビルドします. デフォルトでは 1 コアしか使わないので, CPU のコア数に応じて -j8 などを追記ください.

実例

https://github.com/syoyo/openvdb-android

の README と boost/user-config.jam を参考ください.

TODO

  • link 周りを改善する(user-config.jam で ldflags 指定とか). 現状 .so ビルド(link=dynamic)だと -lrt が見つからないなどでエラーが出る.
  • cmake でビルドできるようにしたい(NDK r19c or later で)
  • b2 で lzma などの探索を強制的に disable する
  • ./configure 時にコンパイラ指定とかできるかしらん?
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

通知設定の変更を受け取る(Android 9以上)

ユーザーがアプリの通知を許可しているかどうかをサーバーへ伝えておきたいと思ったときに調べたメモ

アプリがフォアグラウンド時には許可しているかわかるけど、バックグラウンドで通知設定を変更したときはわからないためシステムから通知は来ないのかと調べました。

NotificationManagerにそれらしきActionが定義されていましたがAPI Level 28から...

ACTION_APP_BLOCK_STATE_CHANGED

ACTION_NOTIFICATION_CHANNEL_BLOCK_STATE_CHANGED

実際にBroadcastReceiverを作ってAndroidManifestに追加することで、Actionを受信することができました。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む