資料へのリンクが公開されたらアップデートします
2日目(Progressive web app編)はこちら：http://qiita.com/doc0s/items/45f0896c5e80c318dfce

Location

2016/04/25 13：30-17：30
コクヨホール
だいたい300人くらいの会場でほぼ満席

Android Beta Program

開催の目的
- N Preview期間は6ヶ月ある
- フィードバックを得て改善していきたい
Previewについて
- 最初の3つのプレビューは初期段階のテスト環境
  - 既存アプリの互換性問題を早めに潰す
- IssueTrackerでフィードバック
  - 今ならまだ修正してもらえるかも
N android beta Program
- https://www.google.com/android/beta
- N のOTAアップデートが配信される
- 対象はNexus 6以降

Android Studio 2.0 & 2.1

複数バージョンの共存
- Mac: 別名で/Applicationsディレクトリに置く
- アップデートチャネルを切り替える
- 既存の環境を壊さない状態で新しい環境に慣れておく。適切だと判断した時点で全員のバージョンを揃える
Android studio 2.0でビルドすると、Gradle plugin 2.0へのアップデートを促される
- 上げて発生したビルドエラーを一度解決すれば、それ以降はOK
- ただし、build.gradleの内容を1.x系と2.0系で別にする必要があるので例えばテストチームは1系を使い開発チームは2系を使う、ということをやりたければbuild.gradleにそれぞれのコマンドを定義するなどする必要がある。が面倒なので基本的に揃えたほうが良いだろう。
SDKインストールディレクトリは共有しても大丈夫
- 実験用バージョン周りでたまに不具合が出る
  - 例：LayoutEditorがレンダーされない
    - 上部にあるAndroidVersionを下げればOK
Emulator
- 非常にサクサク動く（実機以上）
- ExtendedControlでバッテリー量変更やTelephonyCallなどが可能
- ドラッグ＆Dropでapkインストール可能
- 差分インストールでデプロイが高速化
  - Manifestを変更するとアプリフルビルドになるためこれまでどおりの速さになる（詳細は後述のInstantRun参照）

2.1

N Dev Previewのサポート
JAva8のランタイムサポート
JDK8必須
Jack and Jill必須
- Jack（Java Android Compiler Kit）
- Jill （Jack intermediate Library Linker）

2.0

Dexのビルドが高速化された
- Clean：37.8s→17s
- Incremental: 14.2s -> 5s
ビルド時のメモリ不足解消法

build.gradle（昔）

android {
    dexOptions {
        javaMaxHeapSize "2g"
    }
}

gradle.properties（今後）

org.gradle.jvmargs=-Xmx4096m

シュリンク機能
- 開発時、デバッグ時のビルド向けに不要なメソッドの消去をすることで高速化
- プロダクションではProguardで1dex化
ADBのデプロイ高速化
- 従来のpush/pullに比べ5倍程度に改善
接続中デバイスに特化したパッケージの生成
- 対象デバイスの解像度向けのリソースのみ含むapkをビルド＆転送
InstantRun
- 接続中デバイスの2回め以降のアップデートインストールを高速化
- デバッグビルドのみ
- 一度adb kill serverしたり切断するとやり直し
- APIレベル15以上
- 4つのレベル
  - Hot swap
    - アプリケーション実行状態のまま変更の反映：既存メソッドの実装修正
  - Warm swap
    - Activity再起動でもプロセスキープ
    - リソースのアップデート
  - Cold swap
    - プロセスの再起動
    - メソッドやシグニチャの変更
  - New build & deploy
    - 従来の方式
  - うまく動かないことも多い
    - MultiDex時、Jackでは動かないなど
その他GPU profiler、IntelliJ15ベース、AppIndexing支援など

Android N what's new and support librart update

基本的に情報はここにあります
- http://developer.android.com/intl/ja/index.html
マルチウィンドウ
- 3種類
  - 2分割、自由形式、Picture in Picture(TVのみ)
- 自由にWindowサイズを変えられるがレイアウトはこれまでどおりの指定
  - とくにこれまでにない指定ができるわけではない
- ライフサイクルもこれまでどおり
  - リサイズでもこれまでの画面回転と同じライフサイクルメソッドが呼ばれる（pause,stop,destroy, create,start,resume）
  - 非アクティブなWindowはonPause状態
  - 動画アプリなどでonPauseで再生停止しちゃだめ→onStopで→Q&Aセッションで議論され最終的にGoogleの方々でちゃんと確認するということになった
- API追加
  - AndroidManifest.xml
    - android:resizeableActivity=["true"|"false"]
      - デフォルトtrue
      - APIレベルがM以下はtrueとして扱われる
    - android:supportsPictureInPicture=["true"|"false"]
      - defaultHeight/defaultWidth
  - DP2で追加したAPI(ActivityおよびFragmentへの追加)
    - isInMultiWindowMode
    - isInPictureInPictureMode
    - onMultiWindowModeChanged
    - onPictureInPictureModeChanged
  - View
    - startDragAndDrop
      - View.DRAG_FLAG_GLOBALが指定されているとWindowをまたいでDrag可能
    - cancelDragAndDrop
    - updateDragShadow
Notificationからの直接返信
- setContent(RemoteView)がDeprecated
- setCustomeContentView, setStyleに移行すべし
Java8
- Jackじゃないと使えない
- ラムダを使うときはオブジェクトがNewされていることを意識する
  - onDrawなんかで使うべきではない（GCが大量に走る）
設定>データ使用量>データセーバー
- ユーザがモバイルネットワーク接続時にデータ通信を制限するアプリを指定できる
- connectivityManagerのActiveNetworkの状態を見て通信内容を制御すべし
クイック設定の編集
- Drag&Dropで設定項目を追加、削除、並び替えできる
- Tile,TileServiceといったクラスを調べるべし
特定のディレクトリへの権限要求
その他：Direct Boot, ShortcutManager, ICU4J、NFC Type-F HOstCard Emulation, Android for Workの拡張改善、Vulkan, OpenGL ES3.2
既存機能の動作変更
- Doze
  - 軽いDoze（Light Doze mode）の導入
    - これまでのDozeは給電中ではない、画面がオフ、物理的に動いていない、この3条件で発火
    - Light Doze modeはこのうち物理的に動いていないという条件がなくなる。つまりポケットに入れて歩いているときなどはこれまでのDozeは発火しないがLight Dozeは入る
  - これまでのDozeModeは引き続き存在する
    - これまで通り、ベストプラクティスとしてJobScheduler/GCMで実装する
- Project svelte
  - Androidのパフォーマンスを改善するGoogle社内のプロジェクト
  - その成果として廃止されることとなったIntent：
    - CONNECTIVITY_ACTION（動的にBroadcastReceiverを書くと大丈夫）、ACTION_NEW_PICTURE、ACTION_NEW_VIDEO
  - ACTION_NEW_PICTURE、ACTION_NEW_VIDEOはJobSchedulerに新APIが追加されている
設定＞ユーザ補助＞表示サイズ
- dpとpxの比率を変えることができる
- ただし最大に拡大してもsw320dp
- これまでLayoutを相対指定していれば問題起きないはず
- 画面密度に依存したデータをサーバから取ってくるというような場合にはケアが必要
複数言語の設定

Android NDK/Game/Vulkan updates

Android N developer Previewについて
- DP2でVulkanサポート
- Nは安定性、パフォーマンス改善をメインテーマにしている
挙動の変更
- 低メモリのデバイスに対応
  - 圧縮テクスチャの使用、モデルを軽くするなどしてメモリフットプリントを小さくする
- 新しいセキュリティ
  - /system/lib以下の未公開ライブラリの参照禁止
  - libpng, libcryptoなど
Vulkan対応
- Nexus 6P/5Xのみ（端末にVulkanドライバが必要）
ANdroid NDK
- ndk r11c
- Clangがデフォルトコンパイラ
  - FWはGCCはDeprecated
- SDKマネージャからダウンロード
- 開発はAOSP上で
- バグ報告はgithub上で
  - github.com/android-ndk/ndk
- Vulkan対応はr12から
- 今後NDKは頻繁にアップデートされる。5週に1度のベータリリース、4半期に1度の正式リリース
GooglePlay, 開発ツール
- Google Play Games Services
- Gamer ID, アバター
  - これまではGoogle+が必須だったが必要なくなる
  - システムで一度Play Games Servicesにログインすると、どのゲームからも使うことができる
- Video録画API
  - プレイ動画シェア
  - 実況
- CardboardVR
  - 3dオーディオAPIのサポート
Vulkan
- CPUの負荷を下げる
- HW要件：OpenGL ES 3.1AEP相当（全Androidデバイスのたった5％）
  - 要ドライバ対応
- APIのダイナミックロード推奨
  - 対応端末が少ないので
- Vulkan描画エンジンのTips
  - テクスチャフォーマット
    - ASTCを使うのが推奨
- Vulkanのライフサイクル
  - OpenGLのリソースをいろんなアプリで使いまくると古い方から破棄される
  - Windowの初期化
    - VkSwapchainを作りなおす
  - API使用時にVK_ERROR_DEVICE_LOST
    - リソースを作りなおす
FPL（Fun Propulsion Labs）
- Google内のゲーム開発系のLab
- FlatBuffers
  - 高速シリアライザ-
- FlatUI
  - OpenGLベースのUI
  - Githubで公開中
    - https://github.com/google/flatui

Q&A（ピックアップ）

Swiftが開発言語になるのか
- コアメンバーがJAVA使いなのでまずない
Kotlin
- コミュニティの動向によっては正式サポートもあるかも
- Debuggerも動くはずだし
Jack and Jillへの移行はデメリットも大きいのでは？
- classファイルを作れなくなるのをJack側でなんとかすることを検討中
- コンパイル速度を上げるため
マルチウィンドウサポートのためにはビデオ再生を例にすると、onPauseでストップすべき？onStopでストップすべき？
- マルチウィンドウ観点だと、ビデオを再生している状態でTweetを見たいなどonPauseが呼ばれている状態で別アプリを立ち上げたいケースがあるのでonPauseではなくonStopで停止すべき
- onPauseで再生を続けると、良くない例がありそうなのでGoogle側で確認し後で回答する
Bazelが採用される？
- どこかのサイトでまことしやかに囁かれていたが少なくとも本流にはならなさそう
- Google内の雰囲気的にはしばらくGradleで行くのではないかと思われる
AndroidNでNDK非サポートAPIを使った時の実動作がどうなるか
- 挙動が最終的に警告になるのかクラッシュになるのかは動作を見ないとわからない
OpenCLのサポートはないのか
- RenderScript推進のエンジニアはいなくなった
- AndroidではOpenGLかVulkanを使うのを推奨

所感

全体としてN developer Previewの内容を浅く説明しているにとどまっていていた
- InstantRunのデモを見れたこと、NDKのリリース頻度がアップして今後は開発が活発になる（はず）という情報が得られたこと、GooglePlayGameServiceの情報が得られたことが個人的には収穫
カバー率を下げてでも特定のトピックを技術的に深く説明するほうが有意義だったのではないかと思う
積極的にDeveloperの声を拾いたいという姿勢が見られ、ことあるごとにfeature requestを出すなどフィードバックを求めていた
- 日本語よりも英語でリクエストしたほうが良いとのこと