Dagger 2.11-rc1

Dagger2.10でdagger.androidモジュールがリリースされました.
本稿ではDagger2.10と2.11でリリースされたdagger.androidモジュールの使い方について簡単に紹介したいと思います.

本題へ入る前に, Dagger2.11では当然, 歴代のバージョンで追加されてきた機能を土台にしています.
Daggerを触ったことがない人は Android: Dagger2を.
Subcomponentを使ったことがない人はAndroid: Dagger2 - Subcomponent vs. dependenciesを.
マルチバインディングを使ったことがない人はDagger2. MultibindingでComponentを綺麗に仕上げるを一度読んでから本稿に戻ってくると理解しやすいと思います.

また今回紹介するコードのリポジトリは下記に公開してあります.
Dagger2.11正式リリースタイミングでも更新していくので, よろしければ ⭐️ をお願いします :)

YukiMatsumura/AndroidDaggerSample

Dagger（Dependency Injection）を最大限に活かせるのは, 依存オブジェクトをDagger自身が生成して, 依存性を満たすようにデザインすることでしょう. しかし, AndroidはActivityやFragmentといったOSが生成・管理するオブジェクトがあり, Daggerが全てを生成・管理することができません.
そうした場合, 次のようにフィールドインジェクションを使って依存性を満たすことになります.

publicclassMainActivityextendsActivity {
@Inject Hoge hoge;

@Override
publicvoidonCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
// 必ず最初に実行すること!
    ((App) getContext().getApplicationContext())
        .getApplicationComponent()
        .newActivityComponentBuilder()
        .activity(this)
        .build()
        .inject(this);
// ...
  }
}

これにはいくつかの問題があります.

1. まず, ActivityやFragment, Service, ContentProviderといったOS管理のクラスへインジェクションする数だけコピペコードが出来上がり, メンテナンス性を悪くします.
2. そしてなにより, クラスが依存性を注入するオブジェクト（ComponentやModules）のことについてそれぞれのクラスが知っている必要があるため, Dependency Injectionのコア原則を破っています.

今回紹介するdagger.androidモジュールを導入すると, これらの問題を解決することができます.

NOTE:
android.daggerモジュールはまだBetaバージョンのため今後変更される可能性があります.  
今でもクラス名がリネームされるなどしているため, 他でコードを参考にされる場合はdaggerのバージョンに注意する必要があります.  

本稿では現時点で最新のリリースバージョンDagger2.11-rc1を対象にしています.  
StableのDagger2.10からの変更点もありますので, Dagger2.10を使う場合は変更点にご注意ください.  

Dagger2.10 -> 2.11の変更点：
 - New API: @ContributesAndroidInjector simplifies the usage of dagger.android
 - All HasDispatching*Injectors are renamed to Has*Injector. They also return an AndroidInjector instead of a DispatchingAndroidInjector
 - Added DaggerApplication and DaggerContentProvider

リネーム情報はGitHubのリリースページに記載されています.  
https://github.com/google/dagger/releases

依存ライブラリの追加

まずはDagger2.11のライブラリを追加しないとはじまりません.
build.gradleのdependenciesに次のライブラリを追加します.

// Core dependencies
  compile 'com.google.dagger:dagger:2.11-rc1'
  annotationProcessor 'com.google.dagger:dagger-compiler:2.11-rc1'

// Android dependencies
  compile 'com.google.dagger:dagger-android:2.11-rc1'
  annotationProcessor 'com.google.dagger:dagger-android-processor:2.11-rc1'

// Require if use android support libs.
  compile 'com.google.dagger:dagger-android-support:2.11-rc1'

dagger-android-*なモジュールがDaggerのAndroid拡張です.
プロジェクトでサポートライブラリを使用している場合はdagger-android-supportも必要です.

余談ですが, 手元の環境ではfindbugsのdependencyでコンフリクトが起きたので, 合わせて解消しています.

エラー：
Error:Conflict with dependency 'com.google.code.findbugs:jsr305'in project ':app'. Resolved versions for app (3.0.1) and test app (2.0.1) differ. See http://g.co/androidstudio/app-test-app-conflict for details.

解決： espresso-coreの依存モジュールからjsr305をexcludeしておく
  androidTestCompile('com.android.support.test.espresso:espresso-core:2.2.2', {
    exclude group: 'com.android.support', module: 'support-annotations'
    exclude group: 'com.google.code.findbugs', module: 'jsr305'
  })

Daggerのライブラリを取得したらComponent, Moduleを作成していきましょう.

ActivityのComponent/Module作成

順を追って必要なオブジェクトを作って行きます. まずはMainActivityに紐づくMainComponentの定義から.

MainComponentはこのあと作るアプリケーションコンポーネントのサブコンポーネントとして定義するので@Subcomponentアノテーションをつけます.
さらに, コンポーネントビルダー@Subcomponent.Builderを同じく宣言します.

package com.yuki312.androiddaggersample;

import dagger.Subcomponent;
import dagger.android.AndroidInjector;

@Subcomponent
publicinterfaceMainComponentextendsAndroidInjector<MainActivity> {
  @Subcomponent.Builder
abstractclassBuilderextendsAndroidInjector.Builder<MainActivity> {
  }
}

MainComponentにはAndroidInjectorインタフェースを継承させます.
AndroidInjectorはAndroidのコアコンポーネント（Activity, Fragment, Service, BroadcastReceiver, ContentProvider）に依存性を注入するメソッドinject(T)を定義したインタフェースです.

次にMainModuleを定義します.

import android.app.Activity;
import dagger.Binds;
import dagger.Module;
import dagger.android.ActivityKey;
import dagger.android.AndroidInjector;
import dagger.multibindings.IntoMap;

@Module
public abstract classMainModule {

  @Binds @IntoMap @ActivityKey(MainActivity.class)
  abstract AndroidInjector.Factory<? extends Activity> bindInjectorFactory(
      MainComponent.Builder builder);
}

@ActivityKeyでのMainActivity.class指定は, 後ほど説明する適切なAndroidInjector.Builderを選択するための型情報に必要なものです.
Androidの各コアコンポーネント専用のInjectorを生成するファクトリをここで指定します. AndroidInjectorについては後ほど説明します.

続いてアプリケーションクラス用のAppModule.

package com.yuki312.androiddaggersample;

import dagger.Module;

@Module(subcomponents = { MainComponent.class })
publicclassAppModule {
}

そしてAppComponent.

package com.yuki312.androiddaggersample;

import dagger.Component;
import dagger.android.AndroidInjector;
import dagger.android.support.AndroidSupportInjectionModule;

@Component(modules = { AndroidSupportInjectionModule.class, AppModule.class, MainModule.class })
publicinterfaceAppComponentextendsAndroidInjector<App> {

@Component.Builder
abstract class Builder extends AndroidInjector.Builder<App> {
  }
}

modules={...}にはインジェクションモジュールを含める必要があります.
インジェクションモジュールには次の種類が用意されています.

• AndroidInjectionModule.class（サポートライブラリを使わない場合）
• AndroidSupportInjectionModule.class（サポートライブラリを使う場合）

インジェクションモジュールには, AndroidのコアコンポーネントにinjectするComponent/SubComponentのファクトリクラスであるAndroidInjector.Factoryを値に持つMapがAndroidコアコンポーネント毎に定義されており, それぞれのインスタンスはマルチバイインディングの仕組みで構築されています.

@Module
publicabstractclassAndroidInjectionModule {
 @Multibinds
abstract Map<Class<? extendsActivity>, AndroidInjector.Factory<? extendsActivity>>
activityInjectorFactories();

  @Multibinds
abstractMap<Class<? extendsFragment>, AndroidInjector.Factory<? extendsFragment>>
fragmentInjectorFactories();

  @Multibinds
abstractMap<Class<? extendsService>, AndroidInjector.Factory<? extendsService>>
serviceInjectorFactories();
 ...

AndroidInjectionModule, AndroidSupportInjectionModuleがAndroidInjector.Factoryの管理に必要であることがわかります.
アプリケーション全体に渡るコアコンポーネントを管理するため, 基本的にはApplicationスコープのコンポーネントで管理することになります.
AppComponentにはビルダーAndroidInjector.Builderも忘れずに定義しておきます.

DaggerApplication

次にApplicationクラスの定義です.
Applicationクラスには各Androidコアコンポーネント用のAndroidInjectorを定義する必要があります.
AndroidInjectorはActivityやFragmentといったコアコンポーネントに依存性を注入するためのインジェクター用のインタフェースです.
コアコンポーネント用のインジェクターには次のものがあります.

• HasActivityInjector
• HasFragmentInjector,
• HasServiceInjector,
• HasBroadcastReceiverInjector,
• HasContentProviderInjector
• HasSupportFragmentInjector（dagger-android-support）

それぞれのインタフェースには各コアコンポーネント専用のインジェクターを返すメソッドが定義されているわけですが, Applicationクラスでこれら全てのインジェクターを実装するのは面倒なので, Dagger2.11ではDaggerApplicationクラスが提供されました.

• dagger.android.DaggerApplication（サポートライブラリを使わない場合）
• dagger.android.support.DaggerApplication（サポートライブラリを使う場合）

Dagger2.11-rc1ではサポートライブラリ対応/非対応でクラス名が同じなのでextendsする際には注意が必要です.
また, DaggerApplicationはApplication用のインジェクターを返すapplicationInjectorをabstractメソッドとして定義してあるので, これをオーバーライドしておきます.
これで, Applicationクラスへのフィールドインジェクションもサポートされます.

package com.yuki312.androiddaggersample;

import dagger.android.AndroidInjector;
import dagger.android.support.DaggerApplication;

publicclassAppextendsDaggerApplication {

@Overrideprotected AndroidInjector<? extends DaggerApplication> applicationInjector() {
return DaggerAppComponent.builder().create(this);
  }
}

仕上げ

最後の仕上げにMainActivityでフィールドインジェクションを実装しましょう.

package com.yuki312.androiddaggersample;

...
import dagger.android.AndroidInjection;

publicclassMainActivityextendsAppCompatActivity {

  ...

@OverrideprotectedvoidonCreate(Bundle savedInstanceState) {
    AndroidInjection.inject(this);
super.onCreate(savedInstanceState);
    ...
  }
}

AndroidInjection.inject(this);. たったこれだけです! 簡単ですね:)
従来のComponentやModuleの指定が現れないのでDependency Injectionの原則にも忠実です.

おまけ

dagger-android-support は何者か

dagger.androidの肝はAndroidコアコンポーネントへのインジェクションサポートです.
今回登場した HasSupportFragmentInjector, AndroidSupportInjectionModule, dagger.android.support.DaggerApplicationが主にサポートライブラリ向けのクラスになります.
これらの中身を覗くと, android.support.v4.app.Fragmentのためのバインディングマップであったり, インジェクターであったりの処理が定義されています.
つまり, サポートライブラリのFragmentを使ったinjectionをサポートするためにこれらのライブラリが必要になってきます.
サポートライブラリのFragmentを使わないのであれば必ずしも必要というわけではなさそうですね.

コアコンポーネントのInjectorはどうやって選ばれる？

ActivityやFragmentといったコアコンポーネントのインジェクターはAndroidInjectionModuleに定義されたAndroidInjector.Factoryから生成することができますが, これが設定されているマルチバインディングで構築されたMapからファクトリインスタンスを取り出す操作はDispatchingAndroidInjectorが行なっています.
DispatchingAndroidInjectorはDaggerが生成するオブジェクトであるためアプリケーション側から直接触ることはないと思いますが, dagger.androidの内部動作を把握するには押さえておく必要のあるクラスです.

ContentProviderInjectorとApplicationInjector

Androidの仕組み上, アプリケーションプロセスがCygoteからforkされて開始される際, ContentProviderの初期化はApplicationの初期化より早いです.
つまり, ActivityやBroadcastReceiver, Serviceなど他のコアコンポーネントと唯一異なってContentProviderのonCreate時にはまだApplicationクラスが初期化（onCreate）されていない可能性があります.
DaggerApplicationクラスを覗くとこの辺りをどう解決しているのかをうかがい知ることができます.

// injectIfNecessary is called here but not on the other *Injector() methods because it is the
// only one that should be called (in AndroidInjection.inject(ContentProvider)) before
// Application.onCreate()
@Override
public AndroidInjector<ContentProvider> contentProviderInjector() {
  ...


/**
   * Lazily injects the {@link DaggerApplication}'s members. Injection cannot be performed in {@link
   * Application#onCreate()} since {@link android.content.ContentProvider}s' {@link
   * android.content.ContentProvider#onCreate() onCreate()} method will be called first and might
   * need injected members on the application. Injection is not performed in the the constructor, as
   * that may result in members-injection methods being called before the constructor has completed,
   * allowing for a partially-constructed instance to escape.
   */
privatevoidinjectIfNecessary() {
if (needToInject) {

この他にも, コアコンポーネントのComponent/Module定義を簡略化できる@ContributesAndroidInjectorや, コアコンポーネントインスタンスをパラメータにとるProviderメソッドの提供方法などもありますが, 本稿では割愛します.

ひとまず, dagger.androidパッケージがどのようなものになる予定なのか, 本稿で大まかにでも掴めたようでしたら幸いです.
rcがとれて, Dagger2.11が正式リリースされたタイミングで俯瞰図なども描きたいと思います.

以上です.

従来はコンテンツを他アプリへ共有する際などにダイアログUIが使われていましたが,
昨今では, マテリアルデザインのModal bottom sheetsで説明されているように, ボトムシートUIにするのが一般的です.

ボトムシートを実装するにはいくつか方法がありますが, 既存のダイアログをボトムシートに変更したいだけであれば, AppCompatDialogを継承したBottomSheetDialogFragment/BottomSheetDialogを使うだけで比較的容易に対応できます.

// 継承元をDialogFragmentからBottomSheetDialogFragmentに変更
// public class MyDialogFragment extends DialogFragment
publicclassMyDialogFragmentextendsBottomSheetDialogFragment {

...

@Overridepublic Dialog onCreateDialog(Bundle savedInstanceState) {
    ...
    View view = binding.getRoot();
    MyBottomSheetDialog bottomSheet = new MyBottomSheetDialog(getContext());
    bottomSheet.setContentView(view);

// ボトムシートダイアログを返却する
return bottomSheet;
  }
}

ボトムシートの幅はスクリーンサイズに合わせて最大幅を調節することが推奨されています.

BottomSheetDialogの横幅を決めるためには, ダイアログの場合と同じくウィンドウの幅を調整する必要があります.
ウィンドウの幅はBottomSheetDialogのコンストラクタで指定することができます.

privatestaticclassShareBottomSheetDialogextendsBottomSheetDialog {
@OverrideprotectedvoidonCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);

// 横画面などでボトムシートが間延びしないように最大幅を設ける
    Optional.ofNullable(getWindow())
      .ifPresent(window -> window.setLayout(
        Math.min(displayWidth, maxWidth), 
        ViewGroup.LayoutParams.MATCH_PARENT);    

また, ボトムシート自体をどこまで引き出した状態で表示するかをpeekHeightを使って指定できます. peekHeightはBottomSheetBehaviorで指定することができます.

bottomSheet.setContentView(view);

// 横画面などでもシェアアイコンが表示されるようにダイアログの高さ(peek)を確保する
BottomSheetBehavior behavior 
  = BottomSheetBehavior.from((View) view.getParent());
behavior.setPeekHeight(height);

以上です.

他アプリ起動周りでちょっとハマったのでメモ.

テキストやURIを暗黙Intentで共有する場合, 自アプリがそれに反応するintent-filterを持っていると, ActivityChooserに表示候補として含まれてしまう場合があります.
自アプリで捌きたくないから他アプリに共有しているのに, そのリストに自アプリが載っているのはよろしくない.
ということで, Intentは投げるけれどActivityChooserに自アプリを含めない方法を探りました.

TL;DR

• createChooser, ChooserActivityまわりの挙動がOSバージョンで異なっている
• API LV.23 前後でPackageManager.MATCH_DEFAULT_ONLYの振る舞いが変わる
• API LV.23 前後でActivity選択ダイアログのレイアウトが変わる
• 結論queryIntentActivitiesからの自前ダイアログ生成のが楽そう

シンプルにqueryIntentActivitiesとIntent.createChooserを組み合わせればできるだろうと思っていたのですが, 古いOSで確認したところ意図した通りに動きませんでした.
で, 古いOSでの動作もサポートすべく, 色々検討した結果を残しておきます.

createChooser

Intent intent = new Intent(Intent.ACTION_VIEW, Uri.parse(uri));
int flag = Build.VERSION.SDK_INT >= Build.VERSION_CODES.M ? PackageManager.MATCH_ALL
    : PackageManager.MATCH_DEFAULT_ONLY;
List<ResolveInfo> launchers 
  = context.getPackageManager().queryIntentActivities(intent, flag); // *a

// 自アプリを起動対象から除外する
List<Intent> intents = new ArrayList<>();
for (ResolveInfo app : launchers) {
if (context.getPackageName().equals(app.activityInfo.packageName)) {
continue;
  }
  Intent target = new Intent(intent);
  target.setPackage(app.activityInfo.packageName);
  intents.add(target);
}

if (intents.isEmpty()) {
// 起動対象のアプリが見つからなかった
} else {
// createChooserの第一引数のIntentに反応できるアプリが存在しない場合は EXTRA_INITIAL_INTENTS
// の指定が無視されるため, 必ず反応できるIntentを設定する目的でremove(0)を指定する.
  Intent chooser = Intent.createChooser(intents.remove(0), title); // *1
  chooser.putExtra(Intent.EXTRA_INITIAL_INTENTS, intents.toArray(new Parcelable[0])); // *1
  context.startActivity(chooser);
}

ポイントは *1 の部分で, 下記のコードではAPI Lv.23未満だとうまく動作しませんでした.

  Intent chooser = Intent.createChooser(new Intent(), title); // *1
  chooser.putExtra(Intent.EXTRA_INITIAL_INTENTS, intents.toArray(new Parcelable[0])); // *2

EXTRA_INITIAL_INTENTSに目的のIntentを設定すればうまくいきそうなものですが, API Lv.23未満だと *1 の第一引数Intentに反応できるActivityの数が0であった場合に EXTRA_INITIAL_INTENTSが無視される挙動になります（つまりActivityNotFound）
API Lv.23以上ではEXTRA_INITIAL_INTENTSが評価されます.

API Lv.23未満でcreateChooserの第一引数に渡すIntentは, 少なくとも1つ以上のActivityが反応できる必要があるので下記のようなコードになりました.

  Intent chooser = Intent.createChooser(intents.remove(0), title); // *1
  chooser.putExtra(Intent.EXTRA_INITIAL_INTENTS, intents.toArray(new Parcelable[0])); // *2

MATCH_ALL

*a で, PackageManager.MATCH_DEFAULT_ONLYはAPI Lv.23から挙動が変わっています.
API Lv.23未満だと, Category.DEFAULTに反応するActivityを抽出するものでしたが,
API Lv.23以上だと, 「既定で開く」設定されたActivityがある場合はそのActivityしか返却されなくなりました. API Lv.23以上でAPI Lv.23未満と同じ挙動にするためにはAPI LV.23から追加されたPackageManager.MATCH_ALLを指定する必要があります.

int flag = Build.VERSION.SDK_INT >= Build.VERSION_CODES.M ? PackageManager.MATCH_ALL
    : PackageManager.MATCH_DEFAULT_ONLY;
List<ResolveInfo> launchers 
  = context.getPackageManager().queryIntentActivities(intent, flag); // *a

より便利にいくなら, API Lv.23以上でもMATCH_DEFAULT_ONLYでResolveInfoを拾って, 「既定で開く」設定が自アプリになっていなければそのまま起動, 自アプリであれば上記の処理を実行するとすればいけそうです.

この処理でうまくいきましたが, デバイスによってはシェアダイアログのレイアウトが下記のように残念な結果に :(

動作をみる限りでは, createChooserに渡したIntentが1行目に並び, EXTRA_INITIAL_INTENTSに渡したIntentが2行目に並んでいる様子.
これを解決するならシェアダイアログを自前で組む必要がありそうです.
（あるいはcreateChooserの第一引数にどのActivityにもマッチしないnew Intent()といったIntentを指定するなど…）

API Lv.24からEXTRA_EXCLUDE_COMPONENTSなる定数も追加されているので, API Lv.24以上はこれを使えということかもしれませんが, こんなことにOSバージョン分岐させるのも面倒なので, 手っ取り早くやるならqueryIntentActivitiesからの自前ダイアログ作成が安定しているという結論に落ち着きました.

以上です.

tl;dr

• メッセージの過度な表示はユーザを退屈させてしまう
• Android向けライブラリ “Denbun” をリリースした
• Toast, Dialogなどのメッセージ表示頻度を簡単に調整できるライブラリ

はじめに

モバイルプラットフォームでは, ユーザ向けに何かしらのメッセージを表示することがよくあります.
それは, イベントの発生を知らせるものであったり, ユーザのアクションが完了したことを知らせるものであったり, エラーの発生を知らせるものであったりと様々です.
これらのメッセージは重要なものですが, 中には退屈と思われてしまうものもあります.

• ユーザがアプリケーションの振る舞いを学習するのに重要なメッセージが, アプリケーションを使い慣れた後になっては, ただのお節介なメッセージになってしまうケース
• 毎回閉じるだけの”お知らせダイアログ”といった類のもの
• コンテンツの削除確認といった誤操作防止目的のもの
• Backキーを押した際の「アプリケーションを終了しますか？」なもの

ユーザを退屈させないためにも, メッセージの表示頻度を調節することが重要です.

Denbun

メッセージの表示頻度を調整するためのアプローチはいくつかあります.

• ダイアログに「今後表示しない」チェックボックスをつけてユーザ主動でダイアログ表示をやめさせる方法
• 一度しか表示しないような回数限定メッセージ
• 一週間のうち決まった曜日にだけ表示する定期的なメッセージ など…

これらのアプローチをとるためには, 表示設定や表示回数といった内容を永続化して都度, 表示頻度を調整する必要があります.
そこで, メッセージの前回表示時間や表示回数といった情報を保存し, 表示頻度の調整をサポートするDenbunライブラリをリリースしました.

https://github.com/YukiMatsumura/denbun

このライブラリは, 次のようなメッセージ通知を実現したい場合に有効です.

• 「今後表示しない」 オプション付きメッセージ
• N回だけ表示するメッセージ
• 定期的に表示するメッセージ（1週間に1回の頻度で表示. 月曜日に1回だけ表示. etc.）
• N回表示した後は, n時間経過するまで表示しないメッセージ

メッセージの表現系（Dialog, Toast, Snackbar, etc.）は問いません.
このライブラリは, メッセージの前回表示時間や表示回数をSharedPreferenceに保存しており, これらの情報を駆使して”今, メッセージを表示すべきかどうか” を判断することで, メッセージの表示頻度を調整します.

使い方

まず初めに, Application.onCreateなどで, DenbunBoxを初期化します.
DenbunBoxはこのライブラリの起点となる重要なクラスです.

DenbunBox.init(new DenbunConfig(this));

DenbunBoxの初期化が終わったら, メッセージを表現するDenbunインスタンスを取得します.
メッセージの表示頻度の調節はこのDenbunインスタンスを通して行います.

Denbun msg = DenbunBox.get(ID);

Denbunインスタンスのshow()を呼び出すことで, 表示時間や表示回数の情報が更新され永続化されます.

Denbun msg = DenbunBox.get(ID);
msg.shown();

メッセージの最適な表示頻度はメッセージ毎に異なりますので, Denbunインスタンスを取得する際に最適な表示頻度を算出できるFrequency Adjusterを指定します.
例えば, 下記の例は1回限りのメッセージ通知を実現する例です.

// This message is displayed only once.
Denbun msg = DenbunBox.get(ID, new CountAdjuster(1));
...
msg.isShowable(); // true
msg.shown();
msg.isShowable(); // false

あるいは, メッセージを直接的に今後表示しなくすることも可能です.

Denbun msg = DenbunBox.get(ID);
msg.suppress(true);

メッセージによっては表示頻度の計算が複雑になるものもあるでしょうから, Frequency Adjusterは自前のものを実装してDenbunBox.getに指定することもできます.

実際にDialogやToastを表示する際には, DenbunインスタンスのisShowable()の値を確認してから表示すると決められた頻度でメッセージを表示することができます.

テスタビリティ

Denbunライブラリを使ったコードをテストしたい場合は下記が参考になります.
DenbunConfigにはDenbunライブラリとSharedPreferenceのI/Oを取り持つDAOのgetter/setterが用意されています（このメソッドは@VisibleForTestingです）

DenbunConfig conf = new DenbunConfig(app);

// spy original DaoProvider
Dao.Provider origin = conf.daoProvider();
conf.daoProvider(pref -> (spyDao = spy(origin.create(pref))));
DenbunBox.init(conf);

DenbunBox.find(ID).shown();
verify(spyDao, times(1)).update(any());

おわりに

Denbunライブラリを使い始めるには次の一文をbuild.gradleに追記するだけです.
<latest version>には最新のライブラリバージョンを指定してください.

compile 'com.yuki312:denbun:<latest version>'

近々v1.0.0をリリース予定です.
PRやIssueがあればGitHubの方に登録していただけると幸いです.

以上です.

昨日, メッセージの表示頻度を簡単に調整できるライブラリdenbunをリリースしました.

初めてのライブラリリリースなので色々と学びがありました.
本稿ではVisibleForTestingとRestrictToアノテーションについて書き留めます.

• VisibleForTesting
• RestrictTo

VisibleForTesting

フィールドやメソッドのスコープはできるだけ狭くすることが大切ですが, テスタビリティを確保するためにやむなくスコープを広くとる場合があります.
VisibleForTestingは, スコープをテスタビリティのために広く定義していることを明示します.

例えば, Denbunライブラリでは情報の永続化先であるSharedPreferenceとのI/Oをフックできるようにしてテスタビリティを確保しています.

@VisibleForTesting(otherwise = PACKAGE_PRIVATE)
public DenbunConfig daoProvider(@NonNull Dao.Provider provider) { ... }

このメソッドはプロダクションコードではPackage Privateスコープで扱われることを想定し, テストコードではPublicスコープで扱われることを想定しています.
そのため本来あるべきスコープはPackage Privateなのですが, テスタビリティのためにPublicとしています.

メソッドが本来あるべきスコープはVisibleForTestingアノテーションのotherwiseパラメータに指定します.
こうすることで, プロダクションコードにおいてPackage Privateスコープ外からアクセスしてきた場合にインスペクションによる警告が表示されるようになります.

ただし, このアノテーションはクラスファイルに影響を及ぼすものではないので, インスペクションの警告を無視して無理やり要素にアクセスすることは可能です.

VisibleForTestingの真価は, このアノテーションで指定された要素をプロダクションコードで呼び出すとインスペクションの警告によって使い方が間違っていることを教えてくれるところにあります.
これは, javadocにコメントを残す対応よりもはるかに効果的で簡単です. また, 利用側に実装者の意図をインスペクションを通して伝えることができるので利用側にとっても嬉しい機能です. 実際のライブラリ開発では手軽に導入できてアクセス制御で悩むことも減るのでとても便利に使えます.

ただ, 実際にはアクセス制御できていないので, APIを公開することが致命的であるケースにおいてはイミュータブルインタフェースをかませるなどの対応が必要です. （そのようなケースはあまり思い浮かびませんが, セキュリティが必要なSDKなどでは該当しそうです）

RestrictTo

次にRestrictToアノテーションです. これはテストのために用意されたメソッドであることを明示するものです.
VisibleForTestingはテスタビリティのための”スコープ”に着目しているので, そのメソッド自体は想定されるスコープ内であればプロダクションコードで呼ばれることが許されています.
例えば, VisibleForTesting(otherwise = private)なメソッドであればプロダクションコードでもクラス内（privateスコープ内）からの呼び出しが想定されているということです.

一方で, RestrictToはメソッド自体の存在に着目しています.
RestrictTo(TEST)であれば, テストコードからの呼び出しのみを想定しており, プロダクションコードでの呼び出しは想定されません. RestrictTo(LIBRARY)であれば, ライブラリ内での用途に限った要素であることを明示しています.
これはライブラリを作る側としてはとても強力です. これもVisibleForTestingと同じく, 呼び出し側が想定外の呼び出しを行なった場合にインスペクションの警告を表示します.

例えば, Denbunライブラリでは, DenbunBoxの初期化は一度しか行えず, 2回目以降はno-opになるよう実装されています.
しかし, UnitTestをする際にテストケースごとにDenbunBoxを再初期化したくなる場合も想定して, DenbunBoxの状態をリセットするreset()メソッドを用意しています.

@RestrictTo(TESTS) publicstaticvoidreset() { ... }

このメソッドは, ライブラリ内部および, プロダクションコードからの呼び出しも想定していません. テストに限定した利用を想定したものです.

ライブラリを作る際には, こういったアノテーションも活用して, 利用する側に作り手の意図を明示するのも大切だなと感じました.

以上です.

Android1.5~8.0 Walkthrough のセッションに登壇した際のスライドとスピーカーノートメモ、あと喋った内容の文字起こし.

はじまり。

2017年8月に最新のOS Android8.0 コードネーム Oreoがリリースされました.

アプリを Oreo に最適化するには TargetSdkVersion を 26 に上げる必要があります。
TargetSdkVersion を上げることで、Oreoの新機能を十分に活かすことができます。

ここ数年のアップデートでは システムリソースの消費を抑える DozeやAppStandby、バックグラウンド動作制限などがリリースされています。

これによって、ユーザは端末やアプリを使っていないときの バッテリー消費 を抑えることができます。
その一方で, 開発者は OSの仕様変更に対応する必要があります。

バックグラウンド活動のデザイン原則というものがあります。

• バックグラウンドの活動を減らすことができないのか？
• デバイスが充電中の状態になるまで活動を遅らせることができないのか？
• 他の活動とまとめることができないのか？

といったことを考える必要があります。

8.0で バックグラウンド活動が厳格化されたことで 開発者はこれらと “まじめに” 向き合っていく必要があります。

これらの機能を搭載したOSが市場にどれぐらい流通しているのかをグラフにしました。
一番左のグラフは、下から青がAndroid ヌガー, 緑がマシュマロ, 黄色がロリポップ, 赤がキットカット のシェア率を積み上げたものです。

Dozeは マシュマロ以降のOSに搭載されていますので 市場端末の およそ50% がこれを搭載しています。
Android ヌガーでリリースされた, 一部のBroadcastを無効にするProjectSvelteは 18% です。

この割合は DevelopersサイトのDashboardで公開されている 10月時点でのWorldWideなOSバージョンシェアの数字になります。国内に限定したり、ターゲットユーザ層やminSdkでそもそもサポートしていないOSがあると思いますので、みなさんのサービスと同じ数字にはならない点にご注意ください。

本日は、こういった仕様変更や動作制限の移り変わりを Android 1.5~8.0まで 振り返ります。
時間の都合上、厳選してピックアップしている点はご了承ください。

まず初めは2009年4月リリースのOS1.5 CUPCAKEです.

2009年といえば バラク・オバマ氏が アメリカ合衆国大統領に就任した年 になりますね。
その頃Androidは スクリーンキーボードのサポートやアプリウィジェットプロバイダーをリリースしていました。

リリース：2009年4月 Android1.5 - Api Lv.3

3rd party keyboards… サードパーティ製のキーボードはこの頃からサポート.
Bluetooth A2DP… BluetoothプロファイルのA2DPがサポートされました. 当然まだBLEはサポートされていません.
AppWidgetProvider… アプリウィジェット機能のAPIがリリースされ, 開発者はアプリウィジェットを作成することができるようになりました.

次にリリースされたのが 2009年9月 OS1.6 DONUT です。
Cupcakeでは 320ピクセル x 480ピクセル の解像度のみをサポートしていましたが、Donutからは複数の解像度を扱えるようになりました。
また、バッテリー問題が今よりも はるかに深刻だった時代で, アプリ毎のバッテリー使用量をユーザが確認できる機能などが追加されました。

リリース：2009年9月 Android1.6 - Api Lv.4

Battery usage indicator… アプリごとの消費電力がわかる画面を搭載
当時は電力消費問題が深刻で朝満充電にしても夕方前にはバッテリー切れという状態.

New Android Market UI… 現Google PlayのUIが大幅刷新.
当時のAndroidアプリは簡素なものが多かっただけに, Android Marketの多彩な表現は開発者の目をひくものだった

Text-to-speech engine… 多言語の音声合成エンジンでテキスト読み上げをサポート. ただし日本語は含まれていなかった.

2009年10月 Donutリリースから わずか1ヶ月後には OS2.0 Eclair がリリースされました。
この頃はOSバージョンアップが 今よりも頻繁にあった時代です。
ここでサービス周りのアップデートがありましたので詳しくみてみます。

リリース：2009年10月 Android2.0~2.1 - Api Lv.5~7

Service.setForeground deprecated… Service.setForegroundが非推奨に.
代わりにService.startForegroundを使う必要がある. さらにフォアグラウンドで動作していることをユーザに伝えるためにOngoing Notificationの登録が必須化された.

Key events executed on Key-up… Android2.0はHOMEやBackといったバーチャルキーをサポートするため, ユーザが誤ってキーダウンしてもドラッグすることでキーイベントをキャンセルすることができるように, キーアップでイベント発火されるように変更された.

Multi-touch… マルチタッチがサポートされて, キーボードで素早く文字入力しても抜けることが少なくなりました

その他… Live WallpaperのAPIリリースもこの時.

まず、2.0のタイミングでService.setForegroundメソッドが非推奨になりました。
2.0未満のOSでは フォアグラウンドサービスを開始するのに 通知アイコン が不要でした。

通知アイコンが必須になったのは2.0からで、これによって、ユーザがバックグラウンドで活動しているアプリの存在に気づき、
無用なアプリを停止させることができるようになりました。

また、当時はバックグラウンドの活動に対する制限が緩かったので、バックグラウンドにいるアプリプロセスを片っ端からKillしていくタスクキラー系アプリが バッテリー寿命に効くということで流行りました。
アプリ開発者はそうしたキラー系アプリとも戦っていた時代です。

8.0ではサービスの在り方が大きく変わりました。原則、バックグラウンド状態から新しくサービスを起動できなくなったり、startForegroundServiceで起動する場合には5秒以内にフォアグラウンドへ昇格させないとANRが発生するなど厳格化されました。

バックグラウンド活動まわりで使えるAPIに、ロリポップでリリースされたJobScheduler APIがあります。
これの互換性ライブラリとして FirebaseJobDispatcherが API Lv.9から利用可能です。カバー率はほぼ100%です。
JobSchedulerは ロリポップ から使えるAPIなので 78% の端末で使うことができます。

2010年5月にはOS2.2 Froyoがリリースされました。
音声操作機能や、テザリング機能、GCMの前身にあたる C2DM がリリースされたのもこの時です。

リリース：2010年5月 Android2.2 - Api Lv.8

Install on external storage… アプリのインストール領域に外部ストレージを指定可能になった.

Backup Manager, C2DM… 新しい端末に乗換えした時に便利なアプリデータをクラウドへバックアップ/リストアを実現するAPI Backup Managerがリリース.
アプリはBackup agentを実装することでこれを実現することができる. 現在のバックアップの仕組みとは少し異なる. またGCMやFCMの前身にあたるC2DMもこのOSからサポートされています. C2DMはGCMにリプレースされた時点で非推奨になっています.

JIT compiler… JITコンパイラサポートにより2~5倍高速化. マニフェストに vmSafeMode=falseを指定することでJITコンパイラによる最適化を無効化することができます. このオプションは後々AOTコンパイラを無効化するオプションに置きかわります.

その他… PlayServiceはこれ以前のバージョンでは対応していない.

2010年12月には OS2.3 Gingerbreadがリリースされました。
電池が何に使われたかを計測するバッテリー管理機能などが強化されています。

Androidのイースターエッグが搭載されたのもGingerbreadからです。
Gingerbreadでは ゾンビ ジンジャーブレッドマン の絵がイースターエッグで表示されます。
実際、ジンジャーブレッドは ゾンビ な状態になります。

スマホ向けOSの最新版としての期間が長かったことと、スマホブームが重なったこともあって 一時期は全体の60%を超えるシェアにまでGingerbreadは普及しました。
その後は、2015年にマシュマロがリリースされて、ようやくGingerbreadのシェアが10%を切ったぐらいに ”ゾンビ” な状態でした。

リリース：2010年12月 Android2.3 - Api Lv.9/10

2010年… 東北新幹線全線開業した年.

1touch word selection & copy/paste… テキストのロングプレスで単語が選択されフリー選択モードに移行するようになった.

Improved Power management… アプリがバックグラウンドで消費したCPUタイムをユーザが見られるようになるなどバッテリー管理機能が強化された.

その他… StrictMode搭載. Apache Harmony 6.0ベース化. システムアプリやシステムUIの刷新. Google PlayServiceのサポートはここから.

ここで、パフォーマンスに関する仕様変更についてみてみます。
OS5.0から実行環境がARTに置き換わりましたが、それまではDalvikでした。

OS2.2でJITコンパイラが搭載されたことで CPU使用率の高いコードのパフォーマンスが 最大で5倍改善されました。
OS2.3ではコンカレントGCが採用され、いわゆる”Stop the world”が改善されています。
OS5.0でランタイムがARTに置き換わり、OS7.0ではARTにJITコンパイラが採用されています。

JITコンパイラの採用によってDEXを ジャストインタイム方式で 実行形式にコンバートすればよくなるので、
アプリのインストールやアップデート、OSバージョンアップの時間が大幅に短縮されています。

ランタイムやコンパイラやGCアルゴリズムの違いによってパフォーマンスに差がでる場合もありますので、
ランタイムの違いぐらいは覚えておいて損はないと思います。

ARTはキットカットでも利用できますが オプショナルです。
標準搭載されたのはロリポップ以降ですので 78% の端末に搭載されています。

2011年 2月には OS3.0 Honeycomb がリリースされました。
なかには 黒歴史 という人もいるハニカムですが、重要なアップデートが多くあった OS です。

ActionBar, Fragment, Loader, ハードウェアアクセラレーション, ホログラフィックUIがリリースされています。
ホログラフィックUIはこのスライドデザインのように 黒背景に水色のアクセントカラーをもつテーマで、白背景もバリエーションとしてありましたが、
黒背景が印象的なUIでした。ハニカムは大画面向けのOSで、スマホ向けには配信されていません。

リリース：2011年2月 Android3.0 - Api Lv.11/12/13

New UI design for tablets… Android3.0はタブレットデバイスのような大画面向けのアップデートですが, その内容は後々スマホ向けにも展開され非常に重要なアップデート内容が多く含まれている.

ActionBar, Fragment, Loader… アプリのUI要素にActionBarが導入されました. ActionBarにはMenuキーをエミュレートするオーバーフローメニューが導入されました. また, ActivityをFragmentというサブコンポーネントに分割してMaster-Detail Flowのような柔軟な画面デザインを提供することができる. 開発者は画面の大きさが異なるスマートフォンとタブレット両方で動作するアプリケーションを効率よく作成できるようになります. またActivityやFragmentからの非同期ロードをサポートするLoaderも追加.

Holographic UI… システム全体に新しいUIテーマが適用され, デザインが一新されました. アプリはTheme.Holoを指定することでこれを適用できるようになります. Notificationの表現がリッチになり始めたのもこの頃です.

その他… クリップボードへのコピー＆ペースト対応. ハードウェアアクセラレーションサポート.

2011年10月には OS4.0 IceCreamSandwichがリリースされました。
ハニカムの大画面向けUI Frameworkがスマホ向けにも移植され、統一UIフレームワークとなりました。
また、ハードウェアにMenuキーを搭載することが必須でなくなったのもこのタイミングからです。

リリース：2011年10月 Android4.0 - Api Lv.14/15

Unified UI framework… Honeycombで追加されたタブレット向け要素がスマートフォン向けにも引き継がれた. スマホでは画面が小さいことからアクションアイテムがActionBarに収まらない場合, 上下に分割するSplit ActionBarの実装もここから始まります.
ただし, SplitActionBarは現在では非推奨となっています.

MENUボタンがハードウェアに搭載されることは必須ではなくなり, オプションメニューを提供する場合はActionBarにオーバーフローメニューを配置する必要が出てきたのもこのバージョンからです.

2012年 6月には OS4.1 JellyBean がリリースされました。
16ms毎のvsyncやトリプルバッファリングによって、アニメーションやスクロールがより滑らかになりました。
Unicode6対応によって Unicode絵文字にも対応し、また, Google Play Service v1がリリースされたのもこの年です。

リリース：2012年6月 Android4.1~4.3 - Api Lv.16/17/18

Project Butter… 16ms毎のvsyncやグラフィクスのトリプルバッファリングにより, より早く, よりスムーズなユーザ体験を得られるようになりアニメーションやスクロール操作がより滑らかになりました. デバッグツールのsystraceがリリースされたのもこのタイミングです.

Unicode6.0… Unicode6.0絵文字がサポートされたのがこのOSからです. それまでの絵文字はキャリア絵文字でそれぞれ独自の文字コードが割り当てられていましたが, Unicode6.0絵文字がサポートされたことでキャリアを問わず絵文字が使えるようになりました.

Notification styles, GCM … NotificationにBigStyle/InBoxStyle/PictureStyleのスタイルが加わったのがこのバージョン. まだC2DMはGCMにリプレースされた.

その他… 2012年はAndroidMarketがGooglePlayに改名され, Androidアプリ以外のビデオや音楽も扱うストアサービスとして登場した.
GooglePlayServiceライブラリもこの頃にリリースされた. API.18でBluetooth GATTプロファイルに対応も対応した.

Unicode6対応で うれしいことは Unicode絵文字が使えるようになったことですね。
プッシュ文言にUnicode絵文字を使うサービスも増えてきましたが、Unicode絵文字が使えるのはOS4.3からで、それ以前のOSでは文字化けするものがあります。
また, 絵文字に色がついてカラフルになったのはOS4.4からです。

OS5.0では、人間に関わる絵文字はスライドにあるような黄色いキャラクターのグリフに差し替えられました。
OS6.0でUnicode 7と8をサポートし、また「お父さんの絵文字＋お母さんの絵文字＋子供の絵文字」を
Zero Width Joiner の文字コードで連結すると「家族」の絵文字、1文字に置き換わる仕様にも対応しています。

OS7.0ではUnicode9に対応し、5.0で対応されたnonhuman shapeのキャラクターが”人間”の見た目に戻りました。
絵文字には国や宗教、人種、思想に配慮した仕様になっていて複雑ですが、「human shape」な絵文字と Skin toneの文字コードを繋げることで
絵文字の肌の色を変えることができるようになり、絵文字のバリエーションがグッと増えました。

一応、国内キャリア端末は標準絵文字グリフをキャリア絵文字のグリフで上書きしているので、
OSが同じでもキャリアによって絵文字の見た目に違いがでる問題があることも, ここに付け加えておきます。

それぞれのUnicodeバージョンを搭載している端末の割合はこちらの通りで、
Unicode6が 94%、Unicode 7&8が 50%、Unicode 9が 18%です。

2013年 10月にはOS4.4 Kitkatがリリースされました。
エントリーレベルのデバイスでも動作できるように設計されたOSでストレージアクセスフレームワークが搭載されたのもここからです。
WebViewのアップデートもありましたが そちらは後ほどお話しします。

リリース：2013年10月 Android4.4 - Api Lv.19

Support 512MB RAM device… エントリーレベルのデバイスであっても動作するように設計されたOSで, アプリもActivityManager.isLowRamDevice() APIを使うことで低スペックデバイス向けのコンフィグレーションが可能になりました.

Storage Access Framework… これまで端末内のファイルをユーザに選択させたり, 保存場所を指定させる場合に使われるファイルエクスプローラはOSから提供されていませんでした. ストレージアクセスフレームワークを使うことでユーザに一貫したファイルシステムへの参照方法を提供できるようになりました.

Chromium WebView… WebKitがChromiumベースに差し代わりました. これよりChrome Dev Toolsによるリモートデバッグもサポートされるようになった.

その他… RTLサポートが強化されました. それまではテキストの対応しかなく, リソースを重複して持つ必要がありました.

Android4.4からは, バッテリー消費を抑えるためにアラームの発火タイミングが不正確になります。
4.4以降、どうしても正確なアラームが欲しい場合は AlarmManager の setWindow() か setExact() を使うことになります。

Android6.0は Dozeによるデバイスアイドル状態では アラームの発火が保留されます。
アイドル状態でもアラームを正確に発火させたい場合は setAndAllowWhileIdle() か setExactAndAllowWhileIdle() を使うことになります。

ちなみに、アラームはアプリごとに9分間に1回以上発火はされない仕様です。

2014年10月にはOS5.0 Lollipop がリリースされました。
マテリアルデザインによってUI/UXが大きく変更され、ベクタードロワブル や マルチユーザのサポート、
ARTの標準搭載、CPUの64bitアーキテクチャサポートなど、幅広いアップデート内容になっています。

リリース：2014年10月 Android5.0 - Api Lv.21/22

Material Design, Project Volta… マテリアルデザインの導入でUI/UXが大きく刷新された. RecyclerViewやZ軸, シャドウの概念もここから.
また, バッテリー消費を抑えて電池持ちを改善するプロジェクトProject Voltaが明らかにされました. ジョブスケジューラの機能が提供されたことにより, アプリの動作が最適化されバッテリー消費を抑えることに貢献しています.

Overview, Notification, Multi-user… OverviewはこれまでRecentsと呼ばれていた”最近使ったアプリーケション一覧”の機能に相当するものです.
従来は使ったアプリケーションのリストが並ぶだけでしたが, ここに複数のActivityをドキュメントとして追加することができるようになり, マルチタスクにも使えるようになりました. また, Notificationにはプライオリティやカテゴリの概念が追加され, 重要な通知がヘッドアップ表示されるようになったのもこの頃です.

64bit, ART… また, パフォーマンス改善も行われ, ARTランタイム対応や64bit対応もここから始まりました.

その他… Chromium WebViewがPlayStoreからアップデートできるようになった. AndroidHttpClientのメンテナンスが終了・廃止されURLConnectionの使用が必須に. API Lv20はAndroid Wear向けのAPI Lvとして割り当てられた. またディベロッパープレビュー版という提供方法が始まったのもここから.

WebView周りの変更についてみてみると、4.3までのWebViewは WebKit上で動作していましたが, 4.4以降はChromium上で動作します。
5.0では Google Play経由で アップデート可能になり、WebViewのセキュリティパッチが素早くユーザに届けられるようになりました。
WebViewに依存したアプリの開発者は WebViewのアップデート頻度が高くなったので注意する必要があります。

7.0 以降は Chrome APKから WebViewを提供する機能が搭載されています。これによって、メモリ消費が改善されました。
8.0では アプリのWebView がマルチプロセスモードで実行されます。ウェブコンテンツはアプリのプロセスとは別の独立したプロセスで処理されるので、
セキュリティが強化されています。

また、ここに記載していませんが Chrome custom Tab の機能がOS4.1以降で利用できるようになっています。

Chromium版は 93%の端末 に搭載されていて, WebViewを個別にアップデート可能な端末は 78% です。

2015年 10月にはOS6.0 マシュマロがリリースされました。
このあたりからアプリの挙動を変えるアップデートが目立つようになりました。
RuntimePermission, Doze, AppStandbyなどです。

リリース：2015年10月 Android6.0 - Api Lv.23

RuntimePermission… パーミッションモデルに大きな変更が入りました. ユーザはアプリのパーミッションを管理できるようになり, 好きなタイミングで権限を付与/剥奪できるようになります. また, アプリインストール時にパーミッション許可を求めることはせず, アプリの任意のタイミングでユーザにパーミッション付与を求めるようになります.

Doze, App Standby… 電源に接続していない状態で, 一定時間端末を画面オフで放置していた場合にスリープ状態を維持するDozeや, アプリが長時間アイドル状態であった場合にアプリのネットワークアクセスが無効になり, 同期とジョブが保留されるようになりました.

AutoBackup, Do not disturb… アプリデータが自動でGoogle Driveへバックアップできるようになりました. 追加のコードは必要ありません. バックアップを無効にする場合はマニフェストに1行無効にするフラグを定義します. また, Do not disturbモードもこのバージョンからです.

その他… Apache HTTP clientが削除. OpenSSLからBoringSSLに移行. TextSelectionもそれまでの編集モードからpopup windowでアクションを選択するUIに変更されました.

6.0のDoze機能は, 画面OFF かつ 充電中ではない場合 かつ 端末をほとんど動かさない静止状態 にし続けると、
CPU と ネットワーク通信 を一時保留して バッテリーの寿命を延ばす 省電力機能が働きます。

7.0ではDoze状態になる条件が緩和されて、端末が静止していなくてもDoze状態に入ります。
これによって、ポケットにスマホを入れて持ち歩いているような状況でも バッテリー消費を抑えることができるようになりました。

Dozeがリリースされたのは Android マシュマロ以降なので 50%の端末 がこれを搭載しています。

2016年8月には OS7.0 Nougat がリリースされました。
マルチウィンドウやRAMの使用量を削減するProject Svelteによって一部のブロードキャストが廃止されました。
また、ランチャーアイコンにまつわる変更もあります。

リリース：2016年8月 Android7.0/71 - Api Lv.24/25

Multi-window, Screen zoom… スマートフォンやタブレットで画面を分割して2つのアプリを並べて利用できるようになり, AndroidTVではピクチャーインピクチャーがサポートがサポートされました. また視力が低いユーザ向けの補助機能としてスクリーンズームが搭載され, 端末の画面密度設定が変更可能になりました.

Doze2, File security… 従来はDozeモードに突入するためには端末が静止状態である必要がありましたが, Doze2ではこの制限がなくなりました.
また, プライベートディレクトリのアクセス権限が厳格化され, 他アプリにファイルを直接読み書きさせることができなくなりました. これに伴いfileスキームのURIを含むIntentを共有しようとするとセキュリティ例外が投げられるようになっています.

Project Svelte… アプリのバックグラウンド実行を最適化することでRAMの使用量を削減する取り組み. CONNECTIVITY_ACTION、ACTION_NEW_PICTURE、ACTION_NEW_VIDEOの暗黙的なブロードキャストが削除されました. これらのブロードキャストは複数のアプリが同時に起動するため, メモリが逼迫しシステムのパフォーマンスを低下させる要因になるためです.

その他… 3DレンダリングAPIのvulkanがプラットフォームに統合, データセーバ機能の搭載, WebViewがChrome APKから提供される, VRサポート, App Shortcutなど. またこのタイミングでApache HarmonyベースからOpenJDKベースに移行された.

OS4.3 では 一般的なサイズよりも大きく アプリアイコンを表示するランチャーアプリに対応するため,
端末の抽象解像度ではなく、リクエストされたサイズに応じてリソースを返す mipmapリソースがサポートされました。

OS7.1では アプリアイコンを丸く表示するランチャーアプリが増えたため, アプリから丸いアイコンを提供するRound Iconリソースが追加されています。
OS8.0では さらに元のデザインを崩すことなく、自由にアプリアイコンの形を変えることができるAdaptive Iconがサポートされています。

そして 2017年8月の Android8.0 現在に至ります。

リリース：2017年8月 Android8.0 - Api Lv.26

Background execution limits… バックグランドによる動作が大きく制限されました。サービスを開始してもアプリがバックグラウンドに遷移するとサービスは自動で停止されます。
バックグランドからサービス開始したい場合はContext.startForegroundServiceメソッドをコールし, 5秒以内にフォアグラウンドサービスに昇格させる必要があります。
また、暗黙的なブロードキャストも制限されはじめ、JobShcedulerへの移行が推奨されています。

Notification dots, XML font… アプリの通知がランチャーアイコンにドットで表現されるようになったり, フォントをリソースとして扱えるXMLフォントの機能が導入されました。

Alert windows… システムウィンドウより上にアラートウィンドウを表示できなくなりました。アプリはTYPE_APPLICATION_OVERLAYウィンドウを使うことができます。

その他… HttpsURLConnectionが古いTSLバージョンへフォールバックする動作をやめる, WebViewのマルチプロセスモード実行, ANDROID-IDの処理方法変更, クリッカブルなViewがデフォルトでフォーカス可能に変更, スマホ/タブレットでのピクチャーインピクチャーモード対応, AppShortcutの改善, アダプティブアイコン, 最大アスペクト比, マルティディスプレイ, JobScheduler改善など

Android8.0 ではバックグラウンドで実行する動作を制限していますが、多くの場合 ジョブスケジューラに置き換えることができます。

これは ディベロッパーサイトの Intelligent Job-Scheduling というページからの引用で、
　ジョブを賢くスケジューリングすることで、バッテリ寿命といったシステム状態とともに、アプリのパフォーマンスも向上できます。
と書かれています。

バッテリー寿命というのは、モバイルユーザ体験の重要なポイントです。

Android を よりスマートで、より早く、よりパワフルなプラットフォームに仕上げるには、OSのバージョンアップだけではなく、
アプリの最適化によるバージョンアップも必要不可欠です。

OSに最適化する作業は大変ですが、プラットフォームにも デバイスにも また, ユーザにも優しいアプリ開発を心がけたいものです。

発表は以上ですが、本日紹介した内容は時間の都合上、細かな内容は省いています。
みなさんのサービスに関わる部分で気になるものがありましたら、これらのページを参考にしてみてください。

layer-listや selectorなど, リソースがまた別のリソースを参照する場合があります.

<selector ...>
<item android:drawable="@drawable/image01" />
<item android:drawable="@drawable/image02" />

image01や image02がベクタードロワブルの場合は, 新たに image01.xml, image02.xmlと2つのドロワブルリソースを用意する必要があります.

• selectorや layer-listの定義ファイル
• image01.xml
• image02.xml

image01や image02が他リソースでも使われている共通化されたリソースであれば良いのですが, 他では使われず, ここでしか参照されない場合は1つのリソースファイルとしてまとめて定義できた方が管理が楽です.

そうした場合は aapt:attrタグが使えます.

<?xml version="1.0" encoding="utf-8"?>
<selector
  xmlns:android="http://schemas.android.com/apk/res/android"
  xmlns:aapt="http://schemas.android.com/aapt">
<item>
<aapt:attr name="android:drawable">
<vector ...>
<path ... />
</vector>
</aapt:attr>
</item>
</selector>

<aapt:attr>タグで指定したリソースは, aaptによってリソースファイルとして抽出・生成され, name属性名の値は, 親タグの同属性に指定のリソースを設定する動作となります.
この機能は全てのAndroidバージョンで利用できます.

以上です.

SystemEvents, Input Events, Application, Service, Alarm, UI Drawingといった多くの処理はMain Thread(UI Thread) で実行されます.
重要なポイントは, 画面は16ミリ秒の間隔で再描画されているということです.

Why 16ms, Why 60fps?

人間は繋がりのある複数枚の絵が十分な速さで連続していると, それがあたかもアニメーションしているかのように錯覚します. パラパラ漫画やアニメGifの原理です.
アニメーションをスムーズに見せるために, どれだけ素早く画像を表示できるかという点が重要で, 滑らかで流れるようなアニメーションには必要不可欠な要素です.

人間の脳がアニメーションしているように感じるためには, 最低でも12fps程度の速度が必要です. これよりも遅いとパラパラ漫画のようなぎこちない見た目になります. 12fpsという速度はアニメーションには見えてもあまりスムーズには映りません.
24fpsは流れるようなアニメーションに見えますが, これはモーションブラーやビジュアルエフェクトの効果によるものです.
60fpsはモーションブラーやエフェクトなしでスムーズに映ります. これ以上のfpsはほぼ感知できない領域です.

注意すべきは人間の目の明敏さで, フレームレートが60fpsから24fpsに落ちると, 途端にアニメーションのスムーズさを欠いたように感じ, よくない印象を与えることになります.

VSYNC

スムーズなアニメーションを実現するためにも, Androidがどのようにして60fpsを実現しているのかを理解しておきましょう. それには2つの用語を理解しておく必要があります.

リフレッシュレート

1秒間に画面を何回リフレッシュできるかの値で, ハードウェアが定めた一定間隔で実行されます.
単位はHz（ヘルツ）で, 例えば60Hzであれば1秒間に60回のリフレッシュが可能です.

フレームレート

GPUが一秒間で幾つのフレームを描画できるかの値です.
単位はfpsで, 例えば60fpsであれば一秒間に60フレームの描画が可能です.

Synchronized

GPUが画像データを出力し, ハードウェアがそれを画面に表示します.
スクリーンの描画は, これを何度も繰り返しているので, GPUとハードウェアはできる限り一緒に働くことが望ましいのですが, リフレッシュレートとフレームレートは同じ頻度で起こることが保証されていません.

フレームレートがリフレッシュレートより早いと, ティアリングという現象が発生します.
これは, GPUが新しいフレームをメモリに上書きしている最中に, 画面がリフレッシュされてしまい, まだ更新中の画像を描画してしまうことで, 画像が崩れる（部分的に古いフレームが残る）現象です. これを解決するのがダブルバッファリングです.

ダブルバッファリングでは, GPUがバックバッファにフレームを描画し, それが終わるとフレームバッファーと呼ばれる領域にコピーします. 画面をリフレッシュするときはこのフレームバッファから取り出してリフレッシュするわけです. これによって古いフレームへの上書きが行われないので, 中途半端に上書きされた状態にはなりません.

ここで注意しないといけないことのは, 画面のリフレッシュ中にバックバッファからフレームバッファへのコピー作業が発生しないようにすることです. そうしないと, 同じ問題が起こります. ここで登場するのがVSYNC（Vertical Synchronization）です.

通常はフレームレートがリフレッシュレートよりも高いことが望ましいです. なぜなら, 画面を読み込むよりもGPUのリフレッシュの方が早くなるからです.
GPUはフレームをバックバッファに載せると, VSYNCによって次の画面リフレッシュまで処理を待つことになります.

しかし, 反対にフレームレートがリフレッシュレートよりも低い場合, 例えば30fpsに対して60Hzのディスプレイであった場合, フレームバッファのリフレッシュ作業には, 画面リフレッシュの倍の時間を要するため, 同じフレーム内容で2回ずつリフレッシュすることになります.
問題は, これが断続的に起こった場合です.

十分に早いフレームレートで動作しても, 突然フレームレートが落ちると, ユーザはスムーズなアニメーションに続いて, ぶつ切りになったものを見ることになります.
これらの事象は一般的に ラグ, ジャンク, ヒッチング, スタッター と呼ばれます.

アプリの開発者はこれらの事象を避けなければなりません.
人間の目は明敏で, フレームレートが落ちると, 途端にアニメーションのスムーズさを欠いたように感じ, よくない印象を与えてしまうことを思い出してください.

アプリ開発者が目指すところは 常に60fpsのパフォーマンスを維持すること です.

1000ms / 60frames = 16.666ms/frame

MainThreadでは16msの間隔でUI Drawingイベントが発生します. 60fpsの滑らかなアニメーションを実現するためには16ms間隔の描画が必要になります.

Main Thread（UI Thread）

単一スレッドの処理は逐次実行されるため, 順番に処理されていきます. MainThreadも例外ではありません. UI DrawingイベントもMainThreadで実行されるので, もしあなたの処理が長引くとUI Drawingイベントが遅延し, 次のリフレッシュレートのタイミングを逃してしまい, アニメーションで描画されるはずであったフレームが抜け落ちる ドロップフレーム が発生します.
あなたが書いた処理の後には, 常にUI Drawingイベントが待ち構えていることを忘れないでください.

次回に続きます…

レイアウトXMLはどのようなプロセスを経てピクセル情報に変換され, 画面に描画されるのでしょうか？
Androidのパフォーマンスを改善するには, UIレンダリングの仕組みを理解しておく必要があります.

Android Performance. Dropped frameでは画面のアップデートが16ms毎に行われ, これが遅延するとユーザ体験を悪くしてしまうことについて触れました.

アプリが60fpsを維持するためにはMainThreadでの処理を軽くし, 16msごとのリフレッシュレートを逃さないようにしなければなりません.
60fpsを維持できなくする理由はたくさんありますが, 今回はViewの更新とレンダリングパイプラインについて見ていきます.

Layout & Draw

レイアウトXMLがパースされるとレイアウトツリー（ビューヒエラルキー）が作成されます. 描画はルートノードから始まり, ツリーを渡り歩きながらレイアウトと描画が行われます.
複数のビューを持つ親ビュー（ビューグループ）の場合は, 子ビューにいくつかの制約や制限をつけて描画を要求します. 描画の順序は親ビューが先で子ビューが後になるので, 親が子より奥に描画され, 子ビューが親に重なる形で描画されることになります.

ビューのレイアウトにはメジャーとレイアウトのプロセスがあります. 親ビューは子ビューのサイズに依存するので, まずは子ビューのサイズを計測します. 計測が終わると親ビューが全ての子ビューを計算されたサイズで配置していきます. これはビューツリーからトップダウントラバーサルで処理されるため, ビュー階層が浅いほどパフォーマンスが良くなります. ビューのレイアウトが終わるとこれを描画します.

Rasterization

Viewをディスプレイに描画するには, ボタンやテキストをピクセルに変換する必要があります. 例えば, ラスタ形式（ビットマップ, etc.）ではない文字列やボタン, ベクタードロワブルのようなオブジェクトはラスタライズと呼ばれるプロセスでピクセル形式に変換されてから画面に出力されます.
Android3.0以降, レンダリングパイプラインはハードウェアアクセラレーションをサポートしました. ラスタライズはとても時間のかかるプロセスなので, 専用にデザインされたハードウェアユニット（アクセラレータ）で高速に処理されます. これがGPU（Graphics Processing Unit）です.

GPUはポリゴンやテクスチャといったいわゆる画像などのために設計されたハードウェアユニットです. CPUはそういった画像をGPUに供給する役割を果たします. この操作には OpenGL ES のAPIを使って行われています.

ボタンなどのUIオブジェクトを描画したい場合, まずはCPUでポリゴンやテクスチャ情報に変換し, これをGPUに送ってラスタライズします. CPUでポリゴンやテクスチャ情報に変換したり, GPUにこれを入力する処理は高速ではありません.

パフォーマンスのために, これらのオブジェクトに変換する回数を減らすことは効果があります. OpenGL ES のAPIはGPUに入力したオブジェクトをGPU上にそのままキャッシュさせることが可能です. 同じボタンやUIコンポーネントを使う場合は, 単にGPU上に残ったキャッシュを参照すればよいので, 余計なオーバーヘッドが起こりません. レンダリングの性能を最適化するには, GPU上にあるキャッシュを可能な限り長時間保持して, これを再利用するようにすることです.

Display list

標準UIコンポーネントのドロワブルなどはあらかじめGPUに入力されており, これらの描画は効率的に動きます.
しかし, 実際のUIは複雑で, 例えば背景画像といったビットマップはCPUが画像をメモリにロードしてGPUに転送されます. また, ベクタードロワブルはパスを繋げてポリゴンを描画する必要があります.
テキストにいたってはCPUで文字グリフをテクスチャにラスタライズしたあとGPUにこれを入力し, GPUメモリにグリフを参照する領域を描画します.
アニメーションリソースはもっと複雑で, ビジュアルが変わればGPUリソースを1コマ, 1コマ何度も更新しなければなりません.

ハードウェアアクセラレーションが有効である場合, ディスプレイリストを使った新しい描画モデルで描画されます. ディスプレイリストにはGPUレンダリングに必要な情報アセットとOpenGLコマンドリストが格納されていて, 無駄なオーバーヘッドを抑えて効率的に描画することができます.

Draw Phase

ビューが実際にレンダリングされる前に, まずGPUに適した形式に変換するDrawフェーズがあります. これはJavaによるonDrawコマンドで行われますが, Canvasを使ってテッセレートされた複雑なオブジェクトかもしれません.
この変換が終わると, システムによって結果がディスプレイリストとしてキャッシュされます.

Androidではその都度画面全体を再描画することはせず, 更新が必要な領域に絞って描画します. しかし, 多数のビューが無効化（invalidate()）されるとDrawフェーズに多くの時間を費やします. あるいはonDrawで非常に複雑なロジックを抱えているかもしれません.

Execute Phase

作成されたディスプレイリストは2Dレンダラーによって実行されます. ディスプレイリストはOpenGL ES APIを使ってドローされます. これによってGPUにデータが送られ, 最終的にピクセルを画面に送ります.
複雑な描画をするカスタムビューでは, OpenGLが描画できるようにコマンドも複雑になる必要があります. 複雑なビューを描画することは2DレンダラーのExecuteフェーズに多くの時間を費やす原因になります.

画面上でUIオブジェクトの位置が変わった場合は, 同じディスプレイリストをもう1度Executeフェーズを実行するだけです. しかし, 画像のビジュアルが変化すると過去のディスプレイリストが無効になるかもしれません. その場合はDrawフェーズでディスプレイリストを再作成して, 再び実行する必要があります. 画像の描画内容が変わるたびにこのプロセスが繰り返されます. このパフォーマンスは画像の複雑さによって変わるため不正確です.

Process

DrawフェーズとExecuteフェーズが終わるとCPUはフレームのレンダリングが完了したことをGPU/グラフィックドライバーに伝えます. このアクションはブロッキングコールであるため, GPUがコマンドを受け付けたことの応答をCPUは待つことになります.
GPUからのコマンド応答が長くなると, このプロセスも長くなります. プロセスが長くなるのは大抵GPUが多くの仕事をしていることが多いです. 多数の複雑なビューの結果, 多くのOpenGLレンダリングコマンドが必要になりGPUの仕事が増えるのです.

16ms / Frame

16msの間に起こるレンダリングパイプラインは次の通りです.

1. Input（ユーザからの入力）
2. Animation（アニメーション）
3. Measure&Layout
4. Drawing（Draw Phase）
5. Sync/Upload
6. Issuing Commands（Execute Phase）
7. Processing（Process）
8. Misc

これらの時間はProfile GPU Renderingツールで見ることができます. 下図はフレームごとのレンダリングに要した時間を並べたもので, 緑色の水平線が16msを示すラインです. これを超えるとDropped Frameが発生します.

実際にアプリケーションを作成すると, 16ms/フレーム・60fpsを維持することが大変であることを実感できるでしょう. パフォーマンスを改善するには計測して問題のある箇所を特定することを繰り返すことが重要です.

前回と合わせて, 最低限必要な知識は揃いましたので, アプリのパフォーマンスを悪くしている箇所を特定し, それを改善するアプローチについて次回以降に書きたいと思います.

次回に続く…

JSR 305’s @ParametersAreNonnullByDefaultを使うと, @Nullableでアノテートされていないメソッド, 引数, フィールドが @NonNullアノテートされているように解釈され, @NonNullアノテートされているのと同じ振る舞いになります.

プロジェクトによっては, @NonNullを明示することが煩わしく, @Nullableのみを定義することにして, それ以外は @NonNull扱いとするルールを採用しているところもあるかと思います.
ただ, これではIDEが提供するNull安全のインスペクションメッセージによる恩恵を受けることができず, 実装者が “@Nullableをつけ忘れていた” なんて悲劇を招く可能性もあります.

“Tool, not Rules”ということで, デフォルトの振舞いを @NonNullにしたいときは, @ParametersAreNonnullByDefaultが使えます.
このアノテーションはクラス単位でつけることもできますが, 例えば次のようにパッケージ単位でも指定できるため, プロジェクトのデフォルト設定としても役に立ちます.

com.android.myappフォルダに↓のような package-info.javaを用意すれば, パッケージ単位で @NonNullアノテーションが有効になります.

// com.android.myapp.package-info.java
@javax.annotation.ParametersAreNonnullByDefault
package com.android.myapp;

JavaからKotlin化する際には @Nullable / @NonNullが定義されていると, とても移行しやすいですのでおすすめです.

以上です.

ExoPlayer 2.6.0からDownloaderが追加されたので実装を追った際のメモ書き.

Download

ダウンローダの構築に必要な情報を持つビルドパラメータクラスDownloaderConstructorHelper
ダウンローダのコンストラクタ引数に使われる.

publicSegmentDownloader(Uri manifestUri, DownloaderConstructorHelper constructorHelper) {

ダウンロードメイン処理

// SegmentDownloader#download
@Override
publicfinalsynchronizedvoiddownload(@Nullable ProgressListener listener)
throws IOException, InterruptedException {
    priorityTaskManager.add(C.PRIORITY_DOWNLOAD);
try {
      getManifestIfNeeded(false);
      List<Segment> segments = initStatus(false);
      notifyListener(listener); // Initial notification.
      Collections.sort(segments);
byte[] buffer = newbyte[BUFFER_SIZE_BYTES];
      CachingCounters cachingCounters = new CachingCounters();
for (int i = 0; i < segments.size(); i++) {
        CacheUtil.cache(segments.get(i).dataSpec, cache, dataSource, buffer,
            priorityTaskManager, C.PRIORITY_DOWNLOAD, cachingCounters, true);
        downloadedBytes += cachingCounters.newlyCachedBytes;
        downloadedSegments++;
        notifyListener(listener);
      }
    } finally {
      priorityTaskManager.remove(C.PRIORITY_DOWNLOAD);
    }
  }

ダウンロード済みのコンテンツは再ダウンロード時にスキップされる

// CacheUtil#cache(DataSpec, Cache, CacheDataSource, byte[], PriorityTaskManager, int, CachingCounters, boolean)
long blockLength = cache.getCachedBytes(key, start,
          left != C.LENGTH_UNSET ? left : Long.MAX_VALUE);
if (blockLength > 0) {
// Skip already cached data.

MasterPlaylist or MediaPlaylist?

ダウンロードするURLはMasterPlaylist or MediaPlaylist どちらかで, 内部ではMasterPlaylistではない（MediaPlaylistの）場合にSingleVariantMasterPlaylistとして扱うようにしている.

// HlsDownloader#getManifest
@Override
protected HlsMasterPlaylist getManifest(DataSource dataSource, Uri uri) throws IOException {
    HlsPlaylist hlsPlaylist = loadManifest(dataSource, uri);
if (hlsPlaylist instanceof HlsMasterPlaylist) {
return (HlsMasterPlaylist) hlsPlaylist;
    } else {
return HlsMasterPlaylist.createSingleVariantMasterPlaylist(hlsPlaylist.baseUri);
    }
  }

ダウンロードをとめる.

ダウンロードを停止するには Thread.currentThread().interrupt();を使う.
割り込みをチェックする（停止できる）タイミングは

1 . 各セグメント毎の読み込み前
2. セグメントの指定バッファサイズ読み込みの都度

ダウンロードコンテンツの永続化

SegmentDownloaderはオンラインデータソース（dataSource）とオフラインデータソース（offlineDataSource）をそれぞれ持っている.
それぞれのデータソースはDownloadConstructorHelperで生成される.
オンラインデータソースはコンストラクタで指定されたファクトリから生成されるデータソースを持つCacheDataSourceが作られる.
オフラインデータソースはデフォルトでFileDataSourceを持つCacheDataSourceが作られる.
また, オンラインデータソースにはキャッシュに情報を書き込むCacheDataSinkがデフォルトで設定される.

// DownloaderConstructorHelper#buildCacheDataSource
public CacheDataSource buildCacheDataSource(boolean offline) {
    DataSource cacheReadDataSource = cacheReadDataSourceFactory != null
        ? cacheReadDataSourceFactory.createDataSource() : new FileDataSource();
if (offline) {
returnnew CacheDataSource(cache, DummyDataSource.INSTANCE,
          cacheReadDataSource, null, CacheDataSource.FLAG_BLOCK_ON_CACHE, null);
    } else {
      DataSink cacheWriteDataSink = cacheWriteDataSinkFactory != null
          ? cacheWriteDataSinkFactory.createDataSink()
          : new CacheDataSink(cache, CacheDataSource.DEFAULT_MAX_CACHE_FILE_SIZE);
      DataSource upstream = upstreamDataSourceFactory.createDataSource();
      upstream = priorityTaskManager == null ? upstream
          : new PriorityDataSource(upstream, priorityTaskManager, C.PRIORITY_DOWNLOAD);
returnnew CacheDataSource(cache, upstream, cacheReadDataSource,
          cacheWriteDataSink, CacheDataSource.FLAG_BLOCK_ON_CACHE, null);
    }

オンラインデータソースではcacheWriteDataSourceの設定が行われる.
DownloaderConstructorHelper#buildCacheDataSourceで特に指定がない限り,
cacheWriteDataSourceには, オンラインデータソース（upstream）とCacheDataSinkが設定されたTeeDataSourceが指定される.
これで, オンラインデータソースの情報がCacheに保存される.

// CacheDataSource#CacheDataSource(...)
  public CacheDataSource(Cache cache, DataSource upstream, DataSource cacheReadDataSource,
      DataSink cacheWriteDataSink, @Flags int flags, @Nullable EventListener eventListener) {
...
if (cacheWriteDataSink != null) {
      this.cacheWriteDataSource = new TeeDataSource(upstream, cacheWriteDataSink);

CacheDataSourceはwriteDataSinkが指定されている場合は, TeeDataSourceをcurrentDataSourceとして設定する.

// CacheDataSource#openNextSource
if (cacheWriteDataSource !=null) {
    currentDataSource = cacheWriteDataSource;
    lockedSpan = span;
    } else {
    currentDataSource = upstreamDataSource;
cache.releaseHoleSpan(span);
    }

TeeDataSourceはオンラインデータソースの情報をdataSinkに書き込みながら読み込み処理を行う.

// TeeDataSource#read
@Override
publicintread(byte[] buffer, int offset, int max) throws IOException {
int num = upstream.read(buffer, offset, max);
if (num > 0) {
// TODO: Consider continuing even if disk writes fail.
      dataSink.write(buffer, offset, num);
    }
return num;
  }

ここで書き込まれているdataSinkはDownloaderConstructorHelperで生成された（デフォルトだと）CacheDataSinkになる.

// DownloaderConstructorHelper#buildCacheDataSource
      DataSink cacheWriteDataSink = cacheWriteDataSinkFactory !=null
? cacheWriteDataSinkFactory.createDataSink()
          : new CacheDataSink(cache, CacheDataSource.DEFAULT_MAX_CACHE_FILE_SIZE);

CacheDataSink.writeによってファイルへの書き込みが行われる.

// CacheDataSink#openNextOutputStream
cache.startFile(dataSpec.key, dataSpec.absoluteStreamPosition + dataSpecBytesWritten,
        maxLength);
    underlyingFileOutputStream =new FileOutputStream(file);
if (bufferSize >0) {
if (bufferedOutputStream ==null) {
        bufferedOutputStream =new ReusableBufferedOutputStream(underlyingFileOutputStream,
            bufferSize);
      } else {
        bufferedOutputStream.reset(underlyingFileOutputStream);
      }
      outputStream = bufferedOutputStream;

// CacheDataSink#write
    outputStream.write(buffer, offset + bytesWritten, bytesToWrite);

書き込まれる対象のファイルはChache.startFileから取得できる.

// SimpleCache#startFile
    return SimpleCacheSpan.getCacheFile(cacheDir, index.assignIdForKey(key), position,
        System.currentTimeMillis());

SimpleCacheSpan.getCacheFileでキャッシュするべきファイルパスを取得できる.

// SimpleCacheSpan#getCacheFile
returnnew File(cacheDir, id + "." + position + "." + lastAccessTimestamp + SUFFIX);

SegmentDownloader.downloadで各セグメントをキャッシュする.

// SegmentDownloader#download
for (int i = 0; i < segments.size(); i++) {
CacheUtil.cache(segments.get(i).dataSpec, cache, dataSource, buffer,
    priorityTaskManager, C.PRIORITY_DOWNLOAD, cachingCounters, true);

CacheUtil.cacheにより, オンラインストリームの情報が永続化される.

// CacheUtil#cache(...)
while (left != 0) {
long blockLength = cache.getCachedBytes(key, start,
        left != C.LENGTH_UNSET ? left : Long.MAX_VALUE);
if (blockLength > 0) {
// Skip already cached data.

キャッシュヒットした場合はオンラインソースからの情報取得をスキップする.

// CacheUtil#cache(...)
if (blockLength > 0) {
      // Skip already cached data.
    } else {
      // There is a hole in the cache which is at least "-blockLength" long.
    blockLength = -blockLength;
    long read = readAndDiscard(dataSpec, start, blockLength, dataSource, buffer,
        priorityTaskManager, priority, counters);

キャッシュヒットしなかった場合はデータソースから読み込む.
このデータソースはTeeDataSourceであるため, オンラインデータソースから読み込みながらキャッシュへ書き込むことになる.

// CacheUtil#readAndDiscard
intread = dataSource.read(buffer, 0,
length != C.LENGTH_UNSET ? (int) Math.min(buffer.length, length - totalRead)
            : buffer.length);

// CacheUtil#cache(DataSpec, Cache, DataSource, CachingCounters)
cache(dataSpec, cache, new CacheDataSource(cache, upstream),
newbyte[DEFAULT_BUFFER_SIZE_BYTES], null, 0, counters, false);

キャッシュインデックスファイル: cached_content_index.exi
キャッシュコンテンツファイル：下記パターンにマッチするファイル名

Matcher matcher = CACHE_FILE_PATTERN_V3.matcher(name);

キャッシュコンテンツのバージョンが古い場合（現時点だと.v1.exo, or .v2.exoなファイル）はアップグレード処理の機能が動く.

// SimpleCacheSpan#upgradeFile
privatestatic File upgradeFile(File file, CachedContentIndex index) {
    String key;
    String filename = file.getName();
    Matcher matcher = CACHE_FILE_PATTERN_V2.matcher(filename);
if (matcher.matches()) {
      key = Util.unescapeFileName(matcher.group(1));
if (key == null) {
returnnull;
      }
    } else {
      matcher = CACHE_FILE_PATTERN_V1.matcher(filename);
if (!matcher.matches()) {
returnnull;
      }
      key = matcher.group(1); // Keys were not escaped in version 1.
    }

    File newCacheFile = getCacheFile(file.getParentFile(), index.assignIdForKey(key),
        Long.parseLong(matcher.group(2)), Long.parseLong(matcher.group(3)));
if (!file.renameTo(newCacheFile)) {
returnnull;
    }
return newCacheFile;
  }

これらに該当しないファイル（ExoDownloader管理外ファイル）は不要ファイルとしてSimpleCache.initialize()で削除される.

// SimpleCache#initialize
    File[] files = cacheDir.listFiles();
if (files == null) {
return;
    }
for (File file : files) {
if (file.getName().equals(CachedContentIndex.FILE_NAME)) {
continue;
      }
      SimpleCacheSpan span = file.length() > 0
          ? SimpleCacheSpan.createCacheEntry(file, index) : null;
if (span != null) {
        addSpan(span);
      } else {
file.delete();
      }
    }

インデックス

CachedContentIndexのコンストラクタパラメータencryptをtrueにすればインデックスファイルが暗号化される.

// CachedContentIndex#CachedContentIndex(File, byte[], boolean)
  public CachedContentIndex(File cacheDir, byte[] secretKey, boolean encrypt) {
    this.encrypt = encrypt;
if (secretKey != null) {
      Assertions.checkArgument(secretKey.length == 16);
try {
        cipher = getCipher();
        secretKeySpec = new SecretKeySpec(secretKey, "AES");
      } catch (NoSuchAlgorithmException | NoSuchPaddingException e) {
        throw new IllegalStateException(e); // Should never happen.
      }
...

// CachedContentIndex#getChipher
    // Workaround for https://issuetracker.google.com/issues/36976726
if (Util.SDK_INT == 18) {
try {
return Cipher.getInstance("AES/CBC/PKCS5PADDING", "BC");
      } catch (Throwable ignored) {
        // ignored
      }
    }
return Cipher.getInstance("AES/CBC/PKCS5PADDING");
...

// CachedContentIndex#writeFile
if (encrypt) {
        byte[] initializationVector = new byte[16];
        new Random().nextBytes(initializationVector);
        output.write(initializationVector);
        IvParameterSpec ivParameterSpec = new IvParameterSpec(initializationVector);
try {
          cipher.init(Cipher.ENCRYPT_MODE, secretKeySpec, ivParameterSpec);
        } catch (InvalidKeyException | InvalidAlgorithmParameterException e) {
          throw new IllegalStateException(e); // Should never happen.
        }
        output.flush();
        output = new DataOutputStream(new CipherOutputStream(bufferedOutputStream, cipher));
      }
...

インデックスファイルを読み込む

// CachedContentIndex#readFile
intcount = input.readInt();
int hashCode = 0;
for (int i = 0; i < count; i++) {
        CachedContent cachedContent = new CachedContent(input);
        add(cachedContent);
        hashCode += cachedContent.headerHashCode();
      }

キャッシュファイルはインデックス情報と紐づけて管理されている.
インデックス情報のクラスはSimpleCacheクラスで生成される.

// SimpleCache#SimpleCache(File, CacheEvictor, byte[], boolean)
this(cacheDir, evictor, new CachedContentIndex(cacheDir, secretKey, encrypt));

インデックス情報はSimpleCacheの初期化時に読み込まれる.

// SimpleCache#initialize
  index.load();

インデックス情報が格納されたファイルは下記のような構造になっており, フォーマットにしたがって順番にロードされる.
（暗号化されている場合はIV情報が格納されて, number_of_CachedContent以降が暗号化される）

privatefinalbyte[] testIndexV1File = {
0, 0, 0, 1, // version
0, 0, 0, 0, // flags
      (byte) 0xFA, 0x12, ..., // IV
0, 0, 0, 2, // number_of_CachedContent
// number_of_CachedContentの分格納される
0, 0, 0, 5, // cache_id
0, 5, 65, 66, 67, 68, 69, // cache_key
0, 0, 0, 0, 0, 0, 0, 10, // original_content_length
      (byte) 0xF6, (byte) 0xFB, 0x50, 0x41// hashcode_of_CachedContent_array
  };


// CachedContentIndex#readFile
  DataInputStream inputStream = new DataInputStream(new BufferedInputStream(atomicFile.openRead()));
int version = input.readInt();
int flags = input.readInt();
if ((flags & FLAG_ENCRYPTED_INDEX) != 0) input.readFully(initializationVector);
intcount = input.readInt();
for (int i = 0; i < count; i++) {
    CachedContent cachedContent = new CachedContent(input);
    add(cachedContent)
    hashCode += cachedContent.headerHashCode();
  }
if (input.readInt() != hashCode) returnfalse;

CachedContentの情報を読み込む際にインデックス情報をメモリにロードする.
上記のインデックス情報にはコンテンツのメタ情報が格納されている.

• id: 元のストリームを識別するためのファイルID
• key: 元のストリームを識別するためのキー
• length: 元のストリームの長さ

// CachedContentIndex#add(CachedContent)
  private void add(CachedContent cachedContent) {
    keyToContent.put(cachedContent.key, cachedContent);
    idToKey.put(cachedContent.id, cachedContent.key);
  }

鍵の保存

HlsDownloader.loadManifestでマニフェストがパース・ロードされる.

// HlsDownloader#loadManifest
    ParsingLoadable<HlsPlaylist> loadable = new ParsingLoadable<>(dataSource, dataSpec,
        C.DATA_TYPE_MANIFEST, new HlsPlaylistParser());
    loadable.load();

ロード時にはTeeDataSourceが設定されたDataSourceInputStreamから読み込まれるため,
マニフェストはこのタイミングで永続化される.

    DataSourceInputStream inputStream = new DataSourceInputStream(dataSource, dataSpec);
try {
      inputStream.open();
      result = parser.parse(dataSource.getUri(), inputStream);

さらに, パース処理ではマニフェストの先頭から各行ごとに解析される.
鍵の情報はSegmentインスタンスにも記録されていく.

// HlsPlaylistParser#parse
if (line.isEmpty()) {
// Do nothing.
        } elseif (line.startsWith(TAG_STREAM_INF)) {
          extraLines.add(line);
return parseMasterPlaylist(new LineIterator(extraLines, reader), uri.toString());
        } elseif (line.startsWith(TAG_TARGET_DURATION)
|| line.startsWith(TAG_MEDIA_SEQUENCE)
|| line.startsWith(TAG_MEDIA_DURATION)
|| line.startsWith(TAG_KEY)
|| line.startsWith(TAG_BYTERANGE)
|| line.equals(TAG_DISCONTINUITY)
|| line.equals(TAG_DISCONTINUITY_SEQUENCE)
|| line.equals(TAG_ENDLIST)) {
          extraLines.add(line);
return parseMediaPlaylist(new LineIterator(extraLines, reader), uri.toString());

// HlsPlaylistParser#parseMediaPlaylist
      } elseif (line.startsWith(TAG_KEY)) {
String method = parseStringAttr(line, REGEX_METHOD);
String keyFormat = parseOptionalStringAttr(line, REGEX_KEYFORMAT);
        encryptionKeyUri =null;
        encryptionIV =null;
if (!METHOD_NONE.equals(method)) {
          encryptionIV = parseOptionalStringAttr(line, REGEX_IV);
if (KEYFORMAT_IDENTITY.equals(keyFormat) || keyFormat ==null) {
if (METHOD_AES_128.equals(method)) {
// The segment is fully encrypted using an identity key.
              encryptionKeyUri = parseStringAttr(line, REGEX_URI);
            } else {
// Do nothing. Samples are encrypted using an identity key, but this is not supported.
// Hopefully, a traditional DRM alternative is also provided.
            }
...
      } elseif (!line.startsWith("#")) {
String segmentEncryptionIV;
if (encryptionKeyUri ==null) {
          segmentEncryptionIV =null;
        } elseif (encryptionIV !=null) {
          segmentEncryptionIV = encryptionIV;
        } else {
          segmentEncryptionIV =Integer.toHexString(segmentMediaSequence);
        }
        segments.add(new Segment(line, segmentDurationUs, relativeDiscontinuitySequence,
            segmentStartTimeUs, encryptionKeyUri, segmentEncryptionIV,
            segmentByteRangeOffset, segmentByteRangeLength));

ここで追加されたSegmentはダウンローダが保存する形式のSegmentに変換される.
プレイリストのセグメント：
HlsMediaPlaylist.Segment#Segment

ダウンローダのセグメント：
SegmentDownloader.Segment

変換はHlsDownloader#addSegmentで行われる.
Segmentに鍵情報が格納されているので, fullSegmentEncryptionKeyUri != nullとなる.
encryptionKeyUrisはHashSetなので, 新しい鍵Uriの場合にencryptionKeyUris.add(keyUri)がtrueを返し,
その鍵のURI情報はDataSpecのuriとして格納され, 一つのセグメントとしてコレクションに追加される.

// HlsDownloader#addSegment
    if (hlsSegment.fullSegmentEncryptionKeyUri != null) {
      Uri keyUri = UriUtil.resolveToUri(mediaPlaylist.baseUri,
          hlsSegment.fullSegmentEncryptionKeyUri);
      if (encryptionKeyUris.add(keyUri)) {
        segments.add(new Segment(startTimeUs, new DataSpec(keyUri)));
      }
    }
    Uri resolvedUri = UriUtil.resolveToUri(mediaPlaylist.baseUri, hlsSegment.url);
    segments.add(new Segment(startTimeUs,
        new DataSpec(resolvedUri, hlsSegment.byterangeOffset, hlsSegment.byterangeLength, null)));

セグメントのコレクションはSegmentDownloaderによってキャッシュされるので, 結果的に鍵情報も同じように永続化される.

for (int i = 0; i< segments.size(); i++) {
        CacheUtil.cache(segments.get(i).dataSpec, cache, dataSource, buffer,
            priorityTaskManager, C.PRIORITY_DOWNLOAD, cachingCounters, true);

.v3.exo

ファイルサイズの上限はCacheDataSource#DEFAULT_MAX_CACHE_FILE_SIZEで定義されており,
デフォルトで2MiB(2 * 1024 * 1024)が指定されている.
これを変更するにはDownloaderConstructorHelperのコンストラクタ引数cacheWriteDataSinkFactoryに自前のDataSink.Factoryを設定する.

Cache cache = new SimpleCache(dir, new NoOpCacheEvictor());
DownloaderConstructorHelper constructor =
newDownloaderConstructorHelper(cache,
new DefaultHttpDataSourceFactory("ExoPlayer", null),
null,
newCacheDataSinkFactory(cache, 20480),
null);

.v3.exoの1ファイルあたりの上限サイズは2MiBがデフォルトで, これを超えると次の.v3.exoファイルに分割保存される.
.v3.exoはSegmentDownloader.Segmentの単位で保存され, のファイル名は
<id>.<ストリームの書き込みバイト位置>.<ファイル書き込み時のタイムスタンプ>.<バージョン>.exo
の形式で決まる.

idはSegmentDownloader.Segmentの単位で管理されており, idが同じであれば同じセグメントを指す.
（SegmentDownloader.SegmentはPlaylistや.ts, 暗号キーといった単位を表現する）
セグメントが変わればidも変わるため, .exoの書き込み容量が上限サイズを迎えていなくても次のファイル名に変わる.

分割保存された.exoファイルを, 後に結合するためには前述のcached_content_index.exiにある
インデックス情報（id, key, content length）を使って復元される.

暗号化

.exiは平文で保存されるのがデフォルトの挙動.
これを暗号化して保存したい場合はSimpleCacheに秘密鍵を渡すことで実現できる.

byte[] secretKey = "Bar12345Bar12345".getBytes("UTF-8")
new SimpleCache(cacheDir, new NoOpCacheEvictor(), secretKey);

val foo = 1
context.getString(R.string.string_format, foo)

↑こういうコードだと, ↓こんなLintエラーが出る.

Errors found:
/xxx/src/xxx/Hoge.kt:100: Error: Wrong argument typefor formatting argument '#1'in string_format: conversion is'd', received <ErrorType> (argument #2inmethodcall) [StringFormatMatches]
setText(context.getString(R.string.string_format, foo))

/xxx/src/main/res/values/strings.xml:100: Conflicting argument declaration here

val foo: Int = 1
context.getString(R.string.string_format, foo)

これだとOK.
静的解析で型推論できずにハマっているのかな？

DataBinding v2にすると

     Caused by: java.lang.NullPointerException: Attempt to invoke interface method 'void android.databinding.Observable.addOnPropertyChangedCallback(android.databinding.Observable$OnPropertyChangedCallback)' on a null object reference
        at android.databinding.BaseObservableField.<init>(BaseObservableField.java:16)
        at android.databinding.ObservableField.<init>(ObservableField.java:73)
        at ...

問題のコードが下記.

private val hoge = ObservableField<Foo?>(null)

これを, 次のように修正することで解決した.

private val hoge= ObservableField<Foo?>()

ボトムシートダイアログの上辺だけを角丸にしたい.

ボトムシートの背景画像を定義する.

<shape
xmlns:android="http://schemas.android.com/apk/res/android"
android:shape="rectangle"
>
<corners
android:bottomLeftRadius="0dp"
android:bottomRightRadius="0dp"
android:radius="1dp"
android:topLeftRadius="12dp"
android:topRightRadius="12dp"
    />
<solidandroid:color="#fff"/>
</shape>

ボトムシートダイアログのレイアウト背景に上記画像を設定する.

<XxxLayout
...
    android:background="@drawable/bg_bottomsheet"
>

このままだと、ウィンドウ背景色が塗りつぶされてしまうので, これを透過するスタイルを用意する.

<style name="AppTheme.ShareDialog" parent="Theme.Design.Light.BottomSheetDialog">
<itemname="android:windowCloseOnTouchOutside">true</item>
<itemname="android:windowIsTranslucent">true</item>
<itemname="android:windowContentOverlay">@null</item>
<itemname="android:colorBackground">@android:color/transparent</item>
<itemname="android:backgroundDimEnabled">true</item>
<itemname="android:backgroundDimAmount">0.3</item>
<itemname="android:windowFrame">@null</item>
<itemname="android:windowIsFloating">true</item>
</style>

スタイルを適用するダイアログを定義する.

privateclassHogeBottomSheetDialog(
  context: Context
) : BottomSheetDialog(
  context,
  R.style.AppTheme_ShareDialog
) {

done.

ダイアログのスタイルには parent="Theme.Design.Xxx.BottomSheetDialog"を継承したものを定義しないと,
Robolectricのテストで attr/bottomSheetStyleが解決できずtest failする.
Github robolectric/robolectric issue 2941

以上.

Exoplayer r2.8.4のダウンローダ機能関連APIのメモ.

r2.6.0の頃はコンテンツをダウンロードするAPIだけが提供されていましたが, r2.8.0からはダウンロードタスクの管理やダウンロード処理の再開、サービスや通知といった部分までサポートされるようになっています.

関連記事：Android: ExoPlayer - Downloader

DownloadManager

DownloadManager
マルチダウンロードストリームの管理とダウンロードリクエストの削除をするクラスです.
このクラスのメソッドはメインスレッド上から呼び出す必要があり, 複数スレッドからの呼び出しは想定されていません.

ダウンロードマネージャは内部ハンドラを持ちます. もしLooperを持たないスレッドからの呼び出しがあった場合, Looper.getMainLooper()によってメインスレッドが取得されます.

次のコードはダウンロードマネージャーを生成します.

// ダウンロードアクションファイルのデシリアライズに必要なクラスを定義
private val DOWNLOAD_DESERIALIZERS = arrayOf(
  DashDownloadAction.DESERIALIZER,
  HlsDownloadAction.DESERIALIZER)

fun initDownloadManager() {
  // ダウンローダの生成に必要なコンストラクタヘルパー
  val constructorHelper = DownloaderConstructorHelper(...)

  // ダウンロードマネージャを生成
  DownloadManager(
    constructorHelper,
    DownloadManager.DEFAULT_MAX_SIMULTANEOUS_DOWNLOADS,
    DownloadManager.DEFAULT_MIN_RETRY_COUNT,
    File( /* アクションファイルを保存するファイルパス */ ),
    DOWNLOAD_DESERIALIZERS)
}

ダウンロードマネージャのコンストラクタパラメータは下記.

publicDownloadManager(
    DownloaderConstructorHelper constructorHelper,
int maxSimultaneousDownloads,
int minRetryCount,
    String actionSaveFile,
    Deserializer... deserializers) {

constructorHelper
ダウンローダを生成するためのコンストラクタヘルパー.

maxSimultaneousDownloads
最大同時ダウンロード本数. デフォルト値は1 (DownloadManager.DEFAULT_MAX_SIMULTANEOUS_DOWNLOADS) です.

minRetryCount
ダウンロードの最小再試行回数. デフォルト値は5 (DownloadManager.DEFAULT_MIN_RETRY_COUNT) です.

actionSaveFile
DownloadActionのシリアライズを保存するファイルパス. アクションを永続化することでプロセスを跨いでアクションを再開することができる. ただし, このファイルをSimpleCacheで使用したフォルダに保存しないこと. （ダウンローダは知らないファイルを削除するため）

deserializers
actionSaveFileに保存されているDownloadActionのデシリアライザ. HlsDownloadAction.DESERIALIZER etc.

DownloadManager.Listener

DownloadManager.Listenerを使ってダウンロードイベントのリスナーを登録することができます.
次のコールバックメソッドを定義してイベントを受け取ることができるようになります.

onInitialized
全てのアクションがリストアされたときに呼び出される.

onTaskStateChanged
タスクの状態が変わったときに呼び出される.

onIdle
アクティブなタスクがなくなったときに呼び出される.

DownloadAction

DownloadAction
コンテンツのダウンロードリクエストやコンテンツの削除リクエストを表現するクラス.
ダウンロードやコンテンツ削除のために必要なパラメータ情報を保持している.
このクラスは自前のシリアライザ/デシリアライザを持っており, 自身のアクションをシリアライズすることで, プロセスを跨いでも同アクションをでシリアライズして再開できるようになっている.

アクションが持つパラメータは下記.

type
アクションのタイプ.
このタイプ値はシリアライズ情報に含まれ, アクションをデシリアライズする際に最適なデシリアライザーを選択するために使用される.

version
アクションのバージョン.
アクションはシリアライザによって永続化される際にバージョン情報を記録する.
これによって保存されたアクションのバージョンを判別でき, バリデーションやマイグレーション処理に使うことができる.

uri
ダウンロードまたは削除するURI.
SegmentDownloaderを継承したクラスであれば, URIフィールドもシリアライズの対象になる.

isRemoveAction
削除アクションであればtrue, ダウンロードアクションであればfalse.
SegmentDownloaderを継承したクラスであれば, URIフィールドもシリアライズの対象になる.

data
アクションのカスタムデータ.
アクションファイルには任意の情報をカスタムデータとしてバイト配列形式で保存することができる.
SegmentDownloaderを継承したクラスであれば, URIフィールドもシリアライズの対象になる.

アクションファイルのフォーマットは次の通り.

// type, version は共通フォーマット
output.writeUTF(action.type);
output.writeInt(action.version);

// 以下はSegmentDownloadAction系のフォーマット. keysについては後述
output.writeUTF(uri.toString());
output.writeBoolean(isRemoveAction);
output.writeInt(data.length);
output.write(data);
output.writeInt(keys.size());
for (int i = 0; i < keys.size(); i++) 
  writeKey(output, keys.get(i));
}

SegmentDownloader - HlsDownloaderの関係と同じく, HlsDownloadActionはSegmentDownloadActionを継承しています.
SegmentDownloadActionの生成方法は下記です.

protectedSegmentDownloadAction(
    Uri manifestUri, 
boolean isRemoveAction, 
    @Nullable String data, 
    K[] keys)

manifestUri
ダウンロードしたいコンテンツのURL（Master/MediaPlaylist etc.）.

isRemoveAction
ダウンロードするアクションの場合はfalse, ダウンロードコンテンツの削除アクションの場合はfalse.

data
カスタムデータを指定したい場合はここに指定する.
DownloadServiceでも参照することができる.

keys
ダウンロードするトラックのキー（HLSであればレンディション. DASHであればレプリゼンテーション）を指定します. keysが空配列の場合はすべてのトラックがダウンロードされる.
この引数をnullにすることはできず, またremoveActionがtrueの場合は空配列である必要がある.

DownloadHelper

ダウンロードアクションを生成する際には, ダウンロード対象のプレイリスト/マニフェストURLと, トラックキー（レンディション / レプリゼンテーション）を指定する必要がある.
トラックキーを取得するにはプレイリスト/マニフェストファイルをダウンロード・パースする必要がある.
DownloadHelperはそうした前準備処理とトラックキー取得、ダウンロードアクションの生成を助けてくれる.

DownloadHelperが提供するヘルパーメソッドは次の通り.

prepare
ヘルパーを初期化する.
この操作にはプレイリストやマニフェストのダウンロードを伴う.
引数callbackにDownloadHelper.Callbackを指定することで初期化の成功・失敗を受け取ることができる.
初期化処理は別スレッドで実行され, コールバックはメインスレッド上で実行される.

getPeriodCount
有効なピリオドの数を取得します.
HLSコンテンツの場合は固定で1が返され, DASHコンテンツの場合はピリオド数が返されます.
このメソッドはヘルパーを初期化した後で呼び出す必要があります.

getTrackGroups
指定ピリオドに含まれるトラックグループを取得します.
HLSコンテンツの場合, Media playlistであれば空が返され, Master playlistであればvariants, audio, subtitleを含むグループを返します.
DASHコンテンツの場合は, 引数periodIndexで指定されたピリオドに含まれるアダプションセットに含まれるレプリゼンテーションのフォーマット配列を返します.
このメソッドはヘルパーを初期化した後で呼び出す必要があります.

getDownloadAction
指定のトラック（レンディション / レプリゼンテーション）をダウンロードするダウンロードアクションを構築します.
引数dataにはダウンロードアクションのコンストラクタ引数dataを指定します.
このメソッドはヘルパーを初期化した後で呼び出す必要があります.

getRemoveAction
コンテンツを削除するダウンロードアクションを構築します.
このメソッドはヘルパーを初期化していない状態でも呼び出すことができます.

次のコードはヘルパーを使ってダウンロードアクションを生成するものです.

val mediaPlaylistUri = ...
val helper = HlsDownloadHelper(mediaPlaylistUri, dataSourceFactory)
helper.prepare(object : DownloadHelper.Callback {
    override fun onPrepared(helper: DownloadHelper) {
      helper.getDownloadAction( ... )

      // TrackKeyのリストは下記の要領で構築できる
      // val trackKeys = mutableListOf<TrackKey>()
      // for (i in0 until helper.periodCount) {
      //   val trackGroups = helper.getTrackGroups(i)
      //   for (j in0 until trackGroups.length) {
      //     val trackGroup = trackGroups.get(j)
      //     for (k in0 until trackGroup.length) {
      //       // 必要ならtrackGroup.getFormat(k)でパラメータを確認してフィルタアウトできる
      //       trackKeys += TrackKey(i, j, k)
      //     }
      //   }
      // }
    }

    override fun onPrepareError(helper: DownloadHelper, e: IOException) {
...
    }
  })

単純にHLSコンテンツのMedia playlistに含まれる全てのレンディションをダウンロードするのであれば, 事前にプレイリストをダウンロードして解析する必要もないので, ヘルパーを使わずに次のように生成します.

HlsDownloadAction(uri, false, data, emptyList())

DonwloadService

DownloadService
バックグラウンドでダウンロード処理を継続維持するためのServiceを継承した抽象クラス.
アプリはこのクラスを継承して必要なメソッドをオーバーライドすることでサービスの管理をExoPlayerに任せることができる.

コンストラクタ引数には次のものがある.

foregroundNotificationId
フォアグラウンドサービス用のNotification ID.

foregroundNotificationUpdateInterval
フォアグラウンドノーティフィケーションをアップデートする間隔（ミリ秒）.

channelId
フォアグラウンドノーティフィケーションで使用されるチャネルID.
チャネルは低優先度のチャネルとして作成される. 自身でチャネルを作成する場合はnullを指定する.

channelName
フォアグラウンドノティフィケーションで使用するチャネル名.
自身でチャネルを作成する場合は特に使用されない.

定義されている抽象メソッドは下記.

getDownloadManager()
コンテンツのダウンロードで使用されるDownloadManagerインスタンスを返す.
このメソッドはサービスのライフサイクルの中で１度しか呼ばれない.

getScheduler()
特定の条件を満たした時にDownloadServiceを初期化するジョブを持ったSchedulerを返す.
これによって, アプリが実行されていなくてもダウンロードを開始するスケジューリングが可能になる.
スケジューリングが不要な場合はnullを返す.

getForegroundNotification
フォアグラウンドサービスに必要なNotificationを生成する. 引数taskState[]を使ってNotification情報を構築することができる.
このメソッドは, タスクの状態が変化するか, アクティブなタスクがあれば定期的に呼び出される.
呼び出し間隔はDownloadServiceのコンストラクタで調整可能.
API Lv.26以降, このメソッドはサービスが停止する前に空のTaskState[]を引数に呼び出される.

抽象メソッドではないが, サブクラスが意識するべきメソッドは下記.

getRequirements
ダウンロード開始条件をカスタマイズすることができる. デフォルトではネットワーク接続の有無がダウンロード条件として設定される.

onTaskStateChanged
タスクの状態が変わった時に呼び出される.

ダウンロードサービスの開始

アプリがバックグラウンドにいる状態でもダウンロード処理を継続したい場合は, ダウンロードサービスをフォアグラウンドサービスとして振る舞わせる必要がある.
DownloadServiceは DownloadService.startForeground(Notification)を使って起動することができる.

// DownloadService
publicstatic void startWithAction(
    Context context, 
Class<? extendsDownloadService> clazz, 
DownloadActiondownloadAction.
booleanforeground)

clazz
作成したDownloadServiceのサブクラスを指定します.

downloadAction
DownloadActionはダウンロードストリーム/コンテンツに対するアクション.
対象のストリーム種別によってProgressiveDownloadAction, HlsDownloadAction, DashDownloadActionなどが用意されている.

foreground
フォアグラウンドサービスとして起動する場合はtrue.

ダウンロードサービスを開始するIntentだけが欲しい場合は次のメソッドを使用する.

DownloadService.buildAddActionIntent

生成されるIntentにはダウンロードアクションを格納する download_actionと, フォアグラウンドサービスとして移動するかどうかのフラグ foregroundが格納される.

ダウンロードサービスは次のメソッドを使うことでダウンロードアクションを指定せずに起動することもできる.

DownloadService.start
DownloadService.startForeground

未完了のダウンロードアクションがある場合や, ダウンロード開始条件が満了された場合, サービスはそれらのダウンロードアクションを再開する.
実行するアクションがなければサービスは即終了する.

ダウンロードタスクの状態

ダウンロードタスクの状態は DownloadManager.TaskStateで表現される.

定義：

STATE_QUEUED：開始待ち
STATE_STARTED：開始済み
STATE_COMPLETED：完了済み
STATE_CANCELED：キャンセル済み
STATE_FAILED：失敗

状態遷移図：

queued<-> started -> (canceled | completed | failed)

ExoPlyerのDownloadManager, DownloadServiceを調べた時のメモ.

中断されたアクションを読み込むタイミング

保存されたActionFileの読み込みタイミングはDownloadManagerを初期化したタイミングとなります.

プロセスの強制終了などでActionを完遂できなかった場合, 保存されたActionFileをプロセス再開後に読み込んでダウンロード処理を再開する必要があります.
保存されたActionFileは DownloadManager.loadActionsによってバックグラウンドスレッド上で読み込まれ, これはDownloadManagerのコンストラクタで実行されます.

コンテンツの削除はバックグラウンド？

コンテンツを削除するにはremove flagをtrueにしたアクションを発行します.
アクションはDownloadServiceで実行されるので, フォアグラウンドサービスとして実行することが可能です.
削除中の通知も DownloadService.getForegroundNotificationで返すNotification objectをカスタマイズすることができます.
また, 通知の雛形として DownloadNotificationUtil.buildProgressNotificationが用意されています.
buildProgressNotification は引数のタスクステートに応じて通知の表示内容を変えるため, ダウンロード中通知や削除中通知もこのメソッドで生成できます.

ダウンロード進捗率を取得する

DownloadManager.Listenerの onTaskStateChangedコールバック引数のTaskStateから間近のダウンロード進捗率が取得できます.
TaskState.downloadPercentageがダウンロード進捗率を格納したフィールドです.
ダウンロード進捗率が未定/不明 あるいは 削除タスクである場合は com.google.android.exoplayer2.C#PERCENTAGE_UNSETがセットされます.
DownloadServiceでは, このコールバックを受けて通知の進捗率を更新するようになっています.

タスクの実行順序とダウンロードのキャンセル

タスクはDownloadManagerによってArrayListで管理されており, 新しいタスクはタスクキュー（タスクリスト）の最後尾に追加され, 先頭から順に実行されます.
DownloadManager.handleActionは新しいダウンロード/削除アクションアクションからタスクを生成してタスクキューの最後尾に追加します.
新しく削除アクションがリクエストされた場合, 既に同じメディアファイルのダウンロードタスクがタスクキューに存在するなら, そのダウンロードを即座にキャンセルします.
つまり, ダウンロード中やダウンロードリクエストをキューイングした後にこれをキャンセルしたい場合は削除アクションを投げるとキャンセルできます.

ダウンロードの開始条件

サービスによっては”従量制ネットワーク接続時にはダウンロードしたくない”といった要件があるかもしれません.
あるいは, “NWが瞬断されてダウンロード中断されたけれど, NW接続が回復したら自動再開したい” 要件があるかもしれません.
ExoPlayer Downloaderではデバイスの状態を監視して, こうした要件に応える機能があります.

RequirementsHelperはデバイスの状態を監視し, 特定の条件を満たした場合にダウンロードを開始/再開するヘルパークラスです. ここで指定できる”特定の条件” は Requirementsクラスで表現され, Requirementsに指定できる条件は次の通りです.

1. ネットワーク種別 ( NW接続済み, 従量制NWに接続済み, ローミング中, etc. )
2. 充電中かどうか
3. アイドル状態かどうか

また, JobSchedulerによる監視もサポートされています.
JobSchedulerを使用する場合は, Requirementsの情報がJobInfoに変換されてスケジューリングされます.

API Lv.によっては判定できるNW種別の種類や, アイドル状態と判定する条件に差異があるので, JobSchedulerやRequirementsのコードを確認した方がよいです.

ダウンロードの開始プロセス

ダウンロードを開始するにはDownloadManagerを初期化して, DownloadServiceを起動し, タスク（アクション）を追加する必要があります.
DownloadServiceは起動されるとRequirementsHelperを起動してデバイス状態を監視し始めます.
デバイスの状態がダウンロード開始条件を満たした場合, いよいよダウンロード処理が開始されます.

RequirementsHelperとスケジューラの生存区間

アプリのプロセスが生きている間はRequirementsHelperが動的ブロードキャストレシーバーを使ってデバイス状態を監視し, ダウンロードを開始/再開させます.
デバイスの監視はDownloadServiceによって開始されますが, ダウンロードが中断されてDownloadServiceが停止してもこの監視は続きます.
これは, デバイスの状態を監視するRequirementsHelperをDownloadServiceのstaticフィールドで保持しているためです.

DownloadServiceがgetSchedulerでスケジューラを指定している場合は, スケジューラでもデバイス状態が監視されます.
スケジューラはAndroid標準のJobSchedulerを使用することができ, これによってアプリのプロセスが停止している場合にもダウンロードを開始/再開させることが可能になります.
スケジューラはダウンロード開始条件が満たされていないと判断された場合にスケジューリングされます.

ダウンロード開始条件が満たされた場合, RequirementsHelperによる監視が続いている（アプリのプロセスが生きている）状態であればRequirementsHelperがダウンロードを開始/再開させて, スケジューラのスケジューリングをキャンセルします.
RequiermentsHelperによる監視がされていない（アプリのプロセスが停止している）状態であればスケジューラによる開始/再開が行われます.

スケジューラだけでデバイス監視しないのは, RequirementsHelper（staticフィールドと動的ブロードキャストレシーバー）を使った方がデバイス状態の検知からダウンロードの開始/再開までを素早く行えるというメリットがあります.

RequirementsとSchedulerとDownloadService

RequirementsとSchedulerは, DownloadServiceのgetSchedulerとgetRequirementsをオーバーライドして指定します.

@Override
protected Requirements getRequirements() {
returnnew Requirements(Requirements.NETWORK_TYPE_ANY, false, false);
  }

@Override
protected PlatformScheduler getScheduler() {
return Util.SDK_INT >= 21 ? new PlatformScheduler(this, JOB_ID) : null;
  }

JobSchedulerを使ったデバイスの監視を実現するため PlatformSchedulerクラスが用意されています. PlatformSchedulerを使うにはAndroidManifest.xmlに次の定義を追加します.

<uses-permissionandroid:name="android.permission.RECEIVE_BOOT_COMPLETED"/>

<serviceandroid:name="com.google.android.exoplayer2.util.scheduler.PlatformScheduler$PlatformSchedulerService"
android:permission="android.permission.BIND_JOB_SERVICE"
android:exported="true"/>

あるいはFirebaseJobDispatcherを使ったスケジューラ JobDispatcherSchedulerも用意されています. JobDispatcherSchedulerを使うにはAndroidManifest.xmlに次の定義を追加します.

<uses-permissionandroid:name="android.permission.RECEIVE_BOOT_COMPLETED"/>

<service
android:name="com.google.android.exoplayer2.ext.jobdispatcher.JobDispatcherScheduler$JobDispatcherSchedulerService"
android:exported="false">
<intent-filter>
<actionandroid:name="com.firebase.jobdispatcher.ACTION_EXECUTE"/>
</intent-filter>
</service>

タスクの状態

開発者はダウンローダへの要求をアクションとして表現します. アクションには ダウンロードと 削除の2種類があり, ダウンローダはこれらをタスクとして処理していきます.
ExoPlayer downloaderはタスクの状態を2種類定義しています.
1つはTaskStateとして外部に公開される状態で下記の状態と遷移を持ちます.

状態リスト：

状態遷移：

┌────────┬─────→ canceled
queued ↔ started ┬→ completed
└→ failed

もう1つは外部に公開されない, DownloadManagerの内部管理用の状態です.
主に, “キャンセル中”や”停止中”といった状態遷移中の状態が定義されています.

内部状態リスト：

内部状態遷移：

Transition map (vertical states are source states):

┌───→ q_canceling ┬→ canceled
│        s_canceling ┘
│         ↑
queued → started ────┬→ completed
↑         ↓         └→ failed
└──── s_stopping

ExoPlayer downloaderを使う上では前者の公開用状態を把握しておけば十分なのですが、ダウンローダの振る舞いを把握するには後者の内部状態を把握しておいた方が理解が進みます。

DownloadManagerのタスク管理と競合

DownloadManagerはタスクの状態変更を DownloadManager.onTaskStateChange検知します.
ここでタスクの状態がアクティブではない場合, タスクの開始が試みられます.
タスクが下記の条件を満たす場合にはアクティブであると判断されます.

/** Returns whether the task is started. */
publicbooleanisActive() {
return currentState == STATE_QUEUED_CANCELING
          || currentState == STATE_STARTED
          || currentState == STATE_STARTED_STOPPING
          || currentState == STATE_STARTED_CANCELING;
    }

要するにタスクが何かしらのアクション中であればアクティブと判断されます.

DownloadManagerは次の条件が全て満たされていることを確認してタスクを開始します.

1. タスクがまだ開始されていないこと（taskstate == queued）
2. 既にあるタスクと競合しないこと
3. ダウンロードタスクの場合, 先行するダウンロードタスクが保留中ではない. かつ, アクティブダウンロード数の上限に達していないこと

1はわかりやすいですね. 既に開始済みのタスクを再び開始することはできないということです.
DownloadManagerは, タスクの状態に関わらずタスクリストの先頭から順番に開始を試みます. 既に開始済みのタスクはここで除外されます.

3の”アクティブダウンロード数の上限”はDownloadManagerのコンストラクタ引数 maxSimultaneousDownloadsが参照されます.
また, これはダウンロードタスクに課せられる条件で, 削除タスクはこの条件に該当しません.

2は少し複雑です. DownloadManagerは次の2点をチェックしてタスク（アクション）の競合を検知します.

1. 同じコンテンツに対するアクションか
2. いずれかのアクションが削除アクションであるか

DownloadManagerはタスクリストの先頭から順番に開始を試みる過程で, 同タスクリスト内の他タスクと競合していないかを検知するためにタスク同士を比較します.
タスクが扱うコンテンツの同一性は DownloadAction.isSameMediaを使って判定され, タスクに紐づくアクションが持つ uriが同じかどうかで判断されます.

/** Returns whether this is an action for the same media as the {@code other}. */
publicbooleanisSameMedia(DownloadAction other) {
return uri.equals(other.uri);
  }

同じコンテンツに対するアクションがタスクリスト内に複数見つかった場合, 比較元あるいは比較先のタスクのいずれかが削除アクションである場合は “競合した” と判定されます.
例えば, とあるコンテンツAをダウンロード中に, 同コンテンツに対して削除アクションを投げるとこの状態になります.

タスクが競合すると, 比較元が削除アクションであれば比較対象のタスクがキャンセルされ, 比較元の削除タスクもスキップされます（キャンセルはされません）.
比較対象のタスクが削除アクションであれば比較元のタスクはスキップされます（キャンセルはされません）.

タスクがキャンセルされるとタスクの状態が変化するので DownloadManager.onTaskStateChangeが呼ばれます. DownloadManager.onTaskStateChangeではタスクの状態がアクティブではない場合にタスクの開始を試みるので, ここで再びタスクの開始が試みられます. スキップされた削除タスクはアクティブにはなっておらず, また競合していたタスクはキャンセルされているので競合は発生しなくなります.

これによって, とあるコンテンツAをダウンロード中に, 同コンテンツに対して削除アクションを投げるとダウンロード処理はキャンセルされて, ダウンロードのキャンセル処理が終了した後に削除処理が行われることになります.

ダウンローダの開始と停止

DownloadServiceが起動されるとRequirementsHelperを登録してデバイス状態の監視を始めます.
デバイスの状態がダウンロード開始条件を満たした場合, いよいよダウンロード処理が開始されます.

DownloadManagerはダウンローダ停止状態を示す downloadsStoppedフィールドを内部に持っています.
このフィールドが falseの時, ダウンロードアクション/タスクが追加されたとしても新しくダウンロードが開始されることはありません.
ダウンローダを開始するには DownloadManager.startDownloadsを呼び出して, このフィールドを trueにする必要があります.

ダウンローダの状態はダウンローダ停止状態がデフォルトですが, 開発者が明示的に DownloadManager.startDownloadsを呼び出してダウンローダを開始する必要はありません.
その理由として, まずDownloadServiceにダウンロードアクションを登録すると, タスクの開始を試みる処理が実行されます.
しかし, このタイミングではダウンローダが停止状態なので, ダウンロードタスクは一旦スキップされます.
スキップされたタスクがどのようにして実行されるのかというと, DownloadServiceがアクション/タスクを追加した後, RequirementsHelperを登録してデバイス状態の監視を始めます.
デバイス状態がダウンロード開始の条件を満たした時, DownloadServiceはDownloadManager.startDownloadsでダウンローダを開始状態にします.
ダウンローダの開始時にはタスクの実行を試みるようになっているので, ここでスキップされたタスクが実行されることになります.

“ダウンロードの開始/停止条件はRequirementsで表現される”と過去の投稿で言いましたが, 厳密には Requirementsはダウンローダの開始条件になります.
ExoPlayerのダウンローダは開始済みであれば全てのタスクを処理しようとします.
このダウンローダは全てのタスクが消化されたとしても, Requirementsの条件が満たされている限り停止しません.
開発者が手動でDownloadManager.startDownload/stopDownloadを呼び出すときは, Requirementsとの整合性が崩れる可能性がある点に注意しなければいけません.

ちなみに, downloadsStoppedはダウンロードアクションに対するものであり, 削除アクションはダウンローダの開始状態に依存しないため, このフィールドが falseであっても削除アクションは実行されます.
つまり, Requirementsを満たしていない状態でもコンテンツの削除は可能です.

備忘録. 走り書き.
Kotlin化するときに苦しんだお話.

Java → Kotlin化する時によく困るのがNullabilityの判断.
ある日, こんな感じのコードに出会った.

class Hoge {
publicfinal String id;
protected String foo;

publicstatic Hoge from(proto HogeProto) {
if (proto == null) thrownew IllegalArgumentException(...);

    Hoge hoge = Hoge(proto.id)
    hoge.foo = Wire.get(proto.foo, HogeProto.DEFAULT_FOO)
return hoge;
  }

privateHoge(String id) { 
this.id = id;
  }
  ...
}

APIコールの応答として HogeProtoを受け取り, それをモデル Hogeに変換させるコード. （Protocol Buffers と Wireライブラリを使ってる）

直したい部分がいくつかある.

まず, proto.idがJavaのString型なので nullの可能性を捨てきれない.
もし, とってもラッキーなことに, 全く正しく疑う余地のない最新のドキュメントが存在していて「idは絶対にnullにならない」って明記されていたり, サーバサイドのコードが assert id != nullの不変条件を表明していたりする場合は, requireNotNull(...)の一文を事前条件として追加できるかもしれない.

publicstatic Hoge from(proto HogeProto) {
    requireNotNull(proto, "...");
    String id = requireNotNull(proto.id, "...");

    Hoge hoge = Hoge(id);
    ....

でも, 残念なことに今回はそんな状況じゃなかった.

ビジネス上, proto.idが nullである可能性が限りなく乏しい状況だけれど, 数千万のユーザを抱えるサービスのエンジニアとしての責任を考えると「大丈夫でしょ♪」と根拠のない自信だけで例外を投げるチェックコードを追加する訳にもいかないし, そんなコードをリリースした夜はきっと眠れない（私は少し心配性）.

サービスやコードの規模が大きくなった後で, こうしたチェックを追加するのはかなり苦労する. この問題は, Hogeクラスのコードを書いたプログラマがちょっと気を利かせて, Hogeクラスの不変条件をコードで表明しておいてくれれば助かるケースだった.

不変条件が追加できると判断できれば, Kotlin化もスムーズに滞りなくできる.

class Hoge (
  val id: String
) {
  companion object {
    fun from(HogeProto proto): Hoge {
      requireNonNull(proto) {...}
      val id = requireNotNull(proto.id) {...}

      Hoge(id)
...
}

IDの不変条件の話はこれぐらいにして, Hogeクラスにはもう一つ問題があった.
でもそれはIDの問題と比べればとっても小さい問題. 相手はフィールド foo.

class Hoge {
  ...
protected String foo;

publicstatic Hoge from(proto HogeProto) {
    ...
    Hoge hoge = Hoge(proto.id)
    hoge.foo = Wire.get(proto.foo, HogeProto.DEFAULT_FOO)
return hoge;
  }
  ...
}

fooのアクセス修飾子は protected. たぶん書いた当時はユニットテストからアクセスさせるためにスコープを広くとったんだと思う.
だったら @VisibleForTestingをつけてほしいけど, まぁ本題じゃないのでそれは横に置いといて…（よくないけど）

実はHogeクラスはモデルというより POJO なクラス. ビジネスロジックを持っている訳でもないし, DTO 的な使われ方をする. Kotlin化で data class になるようなヤツ.
なので, 実際に fooは一度初期化されれば, その後変更されない.

だけれども fooはコンストラクタで初期化されていない.
なので, この状態で フィールドfooの宣言文に @NonNullアノテーションをつけるとIDEが @Not-null fields must be initializedってWarningを表示する（そりゃそうだ）.
何も考えずKotlin化すると lateinitになっちゃうとこだけど, それはこのクラスの実態にあっていないから, そんなことはしたくない.

Kotlin化するときは引数やフィールドのNullabilityをはっきりとさせるためのチェックとして Javaコードに @NonNull, @Nullableを付けてからKotlin化するようにしているけれど, こういう fooのようなコードを書かれると, 問題解消のための一手間が必要になる.

でもこれはIDの問題と比べればとっても小さい問題. fooを finalにすれば解消できる（もちろん, そうできるなら… だけど）

class Hoge {
@NonNullpublicfinal String id;
@NonNullpublicfinal String foo;

publicstatic Hoge from(proto HogeProto) {
    requireNotNull(proto, "...");
    String id = requireNotNull(proto.id, "...");

return Hoge(
      id,
      Wire.get(proto.foo, HogeProto.DEFAULT_FOO)
    );
  }

privateHoge(String id, String foo) { 
this.id = id;
this.foo = foo;
  }
  ...
}

ここまでくれば, すぐにでもkotlin化に着手できる.

ちょっと idの話に戻るけど,,,
HogeProto側にある “デフォルト値” の意味を考えると idも Wire.get(proto.id, HogeProto.DEFAULT_ID)って形で取得した方がいいのかな〜って思ったりする.
でも, 大抵 DEFAULT_IDって空文字だろうし, モデル HogeとしてはIDに空文字を許したくないので, 結局次のようなコードが必要になる.

String id = Wire.get(proto.id, HogeProto.DEFAULT_ID);
if (StringUtil.isNullOrEmpty(id)) thrownew IllegalArgumentException(...);

“空文字を許さない” って部分をちゃんと事前条件として表明できているのはいいことだし, もし DEFAULT_IDが “空文字ではない何か” に置き換わるアップデートが protoにあったとしてもうまく対応できそうだ.

大切にしたいのは, protoはあくまで “APIレスポンスの仕様” ってだけで, クラス Hogeはアプリ内で使われるモデルやデータとして正しい形で存在してなきゃいけないってところ.
Hogeクラスに「こうあってほしい」って考えをコードに落とし込むってところ.

“理解なんてものは概ね願望に基づくものだ” ってセリフがある.
自分の理解をコードを通して他人にも理解させるってとこは, 願望のコード化でもあるなと思った.

閑話休題. 本題のkotlin化に戻る.

Nullabilityもハッキリして, 不変条件まで付いてくればKotlin化はかなり楽になる.
ただ, Hogeのコードには現れていないけれど, Javaの頃によくやった NullObject Patternが意外とKotlin化する上で厄介だったりする.

例えば, もし次のようなコードがあった場合にちょっと困る.

final Hoge EMPTY = Hoge(null);

だいたい, UNKNOWNとか EMPTYみたいな名前と一緒に NullObject Patternが使われている.
↑のケースだと, Hoge.idは nullable (String?)にしなきゃいけなくなるし, わざわざ Hogeが EMPTYかどうかを各所でチェックする必要が出てくる.
nullを許容して Hoge?なプロパティや引数をとる方が isEmptyチェック漏れを心配する必要もない.

Javaの頃はこういうオブジェクトがあればnull-safeなコードが書けたので重宝したけど, Kotlinだと言語レベルでnull-safeをサポートしているので, NullObject Patternの必要性がかなり下がると思った.
むしろ, あると邪魔なケースが多くて, ?や ?:で解決できるようなところをわざわざif (obj !== UNKNOWN)みたいにしなきゃいけないし, nullであってくれたほうが, 型チェック（nullable or not-nullable）の機構が働くので嬉しいことが多い.

特に何もしないデフォルトリスナーとかを NullObjectにしているケースなんかは nullableにしてもさほど困らなさそう.
ただ, nullとNullObjectを明確に区別する使い方をしているケースだと簡単に nullableにはできないので厄介だったりする.

以上, 走り書きでした.

はじめに

i18n対応で考えないといけないことの１つに夏時間（Daylight Saving Time）があります.
夏時間のテストはいくつかの理由で難しい場合が多いです.

• サーバAPI開発中で, 海外へのサービス提供が蓋閉めされている
• 夏時間がくるまで待てない

そこで, 日本でも夏時間が導入されていることにして, 好きなタイミングでJST（Japan Standard Time）↔️JDT（Japan Daylight Saving Time）を切り替えられればテストが捗りそうです.

本稿は, そのような環境を構築するためにTZDB（Time Zone Database）をテスト用に編集して, それをシステムに認識させる方法を紹介します.

本稿執筆時点でのTZDB Versionは2018gが最新です. 以降は最新が 2018gの前提で話を進めます.

ThreeTenBp と ThreeTenABP

ThreeTenBpはTime Zone情報のロード周りでメモリ効率が悪いため, Android向けにThreeTenABPが提供されています.

ThreeTenBpを使用するためにはTime Zone情報を提供する必要があります.
ThreeTenABPはその手続きを肩代わりしてくれるライブラリです.

ThreeTenABPは, ThreeTenBp（/IANA）が提供する TZDB.datを Assetsに内包し, AndroidThreeTen.initでこれを ZoneRulesProviderに登録する AssetsZoneRulesInitializerを実行します.

ThreeTenABPがやっていることはこれだけです.
自前でAssetsZoneRulesInitializerとTZDB.datを用意して, ZoneRulesProviderに登録すれば同じことが実現できるので, 次のようなクラスを用意しておけば, 好きなTZDB.datを登録できるようになります.

class AssetsZoneRulesInitializer(privateval context: Context) : ZoneRulesInitializer() {
overridefun initializeProviders() {
    context.assets.open("TZDB.dat").use {
      ZoneRulesProvider.registerProvider(TzdbZoneRulesProvider(it))
    }
  }
}

// Application.onCreateで下記を実行する
ZoneRulesInitializer.setInitializer(AssetsZoneRulesInitializer(this))

今回は, テスト用に定義した TZDB.dataを作成・登録することで, 擬似的に日本にも夏時間があることにします.

カスタム TZDB.dat 生成手順

1. ThreeTenBP GitHubをクローン
2. IANAから最新のTZDBをダウンロード
3. クローンしたソースの src/tzdb/{tzdb-version}に, 展開したTZDBファイルを移動
4. TZDBを編集
5. mvn clean package -Dtzdb-jarを実行
6. target/threeten-TZDB-{version}.jarから TZDB.datを抽出

1. ThreeTenBP GitHubをクローン

ThreeTenBP GitHubにはTZDBを読み込んでビルドし, TZDB.datを生成するコンパイラ TzdbZoneRulesCompilerがあります.
TzdbZoneRulesProviderに読み込ませるTZDB.datを生成するためにこのレポジトリをクローンします.

2. IANAから最新のTZDBをダウンロード

TZDBを管理するInternet Assigned Numbers Authority（IANA）から最新のTZDBをダウンロードすることができます.

ダウンロードできる種類がいくつかありますが, 今回はタイムゾーン情報があればよいので “tzdata2018g.tar.gz - Data Only Distribution” を選びます.

3. クローンしたソースの src/tzdb/{tzdb-version}に, 展開したTZDBファイルを移動

手順2でダウンロードした tar.gzを展開するとTZDBファイルが入っています.
このTZDBファイルを, 手順1でクローンしたThreeTenBpの src/tzdb/{tzdb-version}ディレクトリに移動します.

クローン直後は srcディレクトリ直下に tzdbディレクトリはないので作成しておきます.
また, 注意点として {tzdb-version}の名前は下記の正規表現にマッチする必要があります

[12][0-9][0-9][0-9][A-Za-z0-9._-]+

OK: 2018g
NG: tzdb-2018g

tar.gzを展開してできるディレクトリ名には余計なプレフィックス tzdb-が入っているので注意が必要です.

最終的に, asiaファイルの場所は下記になります.

{threetenbp-root}/src/tzdb/2018g/asia

4. TZDBを編集

手順3で移動したTZDB情報を編集します.
今回は日本に夏時間があった場合をシミュレーションするため “Asia/Tokyo” リージョンの情報が定義されている {threetenbp-root}/src/tzdb/2018g/asiaファイルを編集します.

日本（Asia/Tokyo）のタイムゾーン情報は 2018gでは次のように定義されています.

# Rule  NAME    FROM    TO  TYPE    IN  ON  AT  SAVE    LETTER/S
Rule    Japan   1948    only    -   May Sat>=124:001:00D
Rule    Japan   19481951    -   Sep Sat>=825:000   S
Rule    Japan   1949    only    -   Apr Sat>=124:001:00D
Rule    Japan   19501951    -   May Sat>=124:001:00D

日本でも過去に夏時間（夏時刻法）があったことがわかります.

TZDBのフォーマットは人間にも読めるようになっています.
フォーマットルールはzic man pageに載っています.
これに則り, 日本に夏時間を導入するため次の１行を追加してみましょう.

RuleJapan  2018  only-Dec  23  00:00  1:00D

これで, TZDB的には 2018/12/23 00:00:00(JST)から日本では夏時間（JDT）が適用されるようになります.

5. mvn clean package -Dtzdb-jarを実行

TzdbZoneRulesCompilerを使って編集したTZDBをもとに TZDB.datを生成します.
ThreeTenBpのルートで下記のコマンドを実行するとTzdbZoneRulesCompilerがビルドを始めます.

mvn clean package -Dtzdb-jar

実行するとビルドログが出力されます.
下記のように Source directory contains no valid source foldersのログが出力される場合はTZDBのディレクトリ名かパスが間違っており, TzdbZoneRulesCompilerがTZDBをうまく認識できていない可能性があります. その場合は手順2をやり直しましょう.

Source filenames not specified, using default set
(africa antarctica asia australasia backward etcetera europe northamerica southamerica)
は, 今回特にファイル名を指定していないので出力されても問題ありません.

...
[INFO] --- exec-maven-plugin:1.2.1:java (default) @ threetenbp ---
Source filenames not specified, using default set
(africa antarctica asia australasia backward etcetera europe northamerica southamerica)
Source directory contains no valid source folders: xxx
...

編集したTZDBがうまく読み込まれなかった場合も BUILD SUCCESSとなるので注意してください. その場合, 後述の threeten-TZDB-2018g.jarが出力されません.

6. target/threeten-TZDB-{version}.jarから TZDB.datを抽出

TzdbZoneRulesCompilerのビルド結果はThreeTenBpプロジェクトルート直下の targetディレクトリに出力されます.
ビルドが成功すると target/threeten-TZDB-2018g.jarが出力されます.

このJarファイルに目的のTZDB.datが含まれているので, それを抽出します.
下記のJarコマンドで内包されているファイルパスの一覧を取得します.

jar tf {threeten-TZDB-2018g.jar のパス}

今回のケースでは org/threeten/bp/TZDB.datにTZDB.datがありました.
同じくJar コマンドでこれを抽出します.

jar -xvf {threeten-TZDB-2018g.jarのパス} org/threeten/bp/TZDB.dat

コマンドを実行したディレクトリに org/threeten/bp/TZDB.datが抽出されます.

テスト

日本にも夏時間が定義されたTZDB.datが作成できたので, これをZoneRulesProviderに登録します.

class AssetsZoneRulesInitializer(privateval context: Context) : ZoneRulesInitializer() {
overridefun initializeProviders() {
    context.assets.open("TZDB.dat").use {
      ZoneRulesProvider.registerProvider(TzdbZoneRulesProvider(it))
    }
  }
}

// Application.onCreateで下記を実行する.
// AndroidThreeTen.initは実行しない（ThreeTenABPは使わない）
ZoneRulesInitializer.setInitializer(AssetsZoneRulesInitializer(this))

この状態で, ZonedDateTimeを使って日本時間表示してみると夏時間が適用されていることがわかります.

ZonedDateTime
.now(ZoneId.of("Asia/Tokyo"))
.format(DateTimeFormatter.ISO_DATE_TIME)

// 出力： 2018-12-23T15:26:19.295+10:00[Asia/Tokyo]

ZoneId.of("Asia/Tokyo").rules.isDaylightSavings(Instant.now())

// 出力：true

以上です.

参考：

• zic man page
• ThreeTen Backport - Update tzdb

/data/data/<Application ID>/配下にADBでファイル追加しようとするとpermission errorで失敗した✍

issueはこれ.
https://issuetracker.google.com/issues/37138359

Android Studioに付属してるFileExplorerを使えばファイルを追加できた.
FileExplorerは次の手順を踏んでいた。

# ファイルを一時領域へコピー 
$ adb push hoge /data/local/tmp 

# アプリユーザに切り替え 
$ adb shell 
$ adb run-as <Application ID>

# ファイルコピー 
$ cp /data/local/tmp/hoge /data/data/<ApplicationID>/hoge

## ↑でエラーが出た場合はcatリダイレクトする
$ cat /data/local/tmp/hohe > /data/data/<Application ID>/hoge

FileExplorerのコードはこの辺.

https://android.googlesource.com/platform/tools/adt/idea/+/studio-3.2.1/android/src/com/android/tools/idea/explorer/adbimpl/AdbDeviceDataDirectoryEntry.java#246

https://android.googlesource.com/platform/tools/adt/idea/+/studio-3.2.1/android/src/com/android/tools/idea/explorer/adbimpl/AdbFileOperations.java#225

以上.