DroidKaigi 2024 参加レポート

はじめに

こんにちは！新卒で IT本部 IT戦略部システム基盤グループ所属の toliner です。

2024/09/11～2024/09/13に、ベルサール渋谷ガーデンで開催された DroidKaigi 2024に現地参加してきました。

プライベートでカンファレンスに参加した事はあったのですが、すべて DroidKaigi よりも小規模なものでした。これほど大規模なものに参加するのははじめてで、少し緊張しました。また、私はAndroidアプリ開発の経験に乏しいので、自身の主要分野とは異なる分野のカンファレンスに挑戦する、という機会でもありました。
参加してみると非常に楽しかったので、その様子をレポートとしてお送りします！

DroidKaigiとは

DroidKaigiは「エンジニアが主役のAndroidカンファレンス」をコンセプトに、Android技術情報の共有とコミュニケーションを目的に開催されるカンファレンスです。
2015年から毎年開催されており、今年は10年目の開催です。DeNAは2018年から今回まで継続してスポンサーとして協賛しています。

会場の様子

会場は1FとB1Fに分かれており、1Fがセッション会場、B1Fがセッション会場と受付・スポンサーブース・コミュニケーションエリアとなっていました。

スポンサーブースではコーヒーやソフトドリンク、お菓子類が配られていました。とくにコーヒーはその場で淹れていて、いつ見ても長蛇の列でした。1回だけ飲みましたが、美味しかったです。

DeNAのブースでは、Code de Crosswordという、コードの穴埋めとクロスワードを組み合わせたクイズを実施していました。問題は時間によって難易度が変更される仕様で、リピート参加の方もたくさんいらっしゃいました。

食事

ランチ

DroidKaigi 2024では、お弁当の提供がありました。今年は3種類の弁当からの選択制でした。
自分はすき焼き弁当以外の2種類、天ぷら弁当と海老カツ弁当を頂きました。会場で前後の人の流れを見ている限り、すき焼き弁当が一番人気だったように思います。メニューの詳細を見ると、海老カツ弁当にもすき焼きが含まれていることが分かったので、「なるべく多くの種類のおかずを網羅的に食べたい」という考えにより、この2種類を選びました。

どちらの弁当も彩り良く、非常においしかったです。カンファレンスの間に良いひと時を過ごすことができました。

ディナー

DroidKaigi 2024では、9/12にAfter Partyがありました。
After Partyは他の参加者と交流を図る場なのですが、非常に豪華な食事が提供されていました。Twitterや他のカンファレンスでの知り合いと交流を深めたり、新しい知り合いを作りながら豪華な食事を食べる時間は、非常に楽しかったです。

セッション内容

DroidKaigi 2024では40を超えるトークセッションが開催されました。

どのセッションも面白く、興味深いものでしたが、とくに気になったものを紹介します。

サプライチェーン攻撃に備える

最初にRyuNen344氏によるサプライチェーン攻撃に備えるというセッションです。

このセッションでは、主にGradleによる依存解決時に、ソフトウェアをサプライチェーン攻撃から守るための方法についての解説が行われました。

サイバー攻撃におけるサプライチェーン攻撃というのは、ソフトウェアやその依存ライブラリに対して、主にバックドアやマルウェアを注入する攻撃のことです。近年、さまざまな大規模ライブラリに対して攻撃が行われており、発覚時にニュースで大きく取り上げられています。サプライチェーン攻撃の手法は、「既存のartifactを改竄する」および「改竄したartifactを新しいバージョンとして公開する」の2つが主です。これに対する防御策の基本は、「信頼できるartifactを取得できるようにする」ことになります。また、依存ライブラリの脆弱性に対する定常的な監視や継続的な更新も必要になります。

Androidアプリ開発において、ライブラリの依存解決等はすべてGradleを用いて行います。そのため、Gradleの機能を活用することで、もっとも効率的にサプライチェーン攻撃に対する防御を行うことが可能です。セッション内では、Gradleが持つサプライチェーン攻撃対策の具体的な利用方法が紹介されていました。

ただし、Gradleにおける検証で確認できるのは、「publisherが公開してから、artifactが改竄されていない」ことだけです。publisherそのものが偽物だったり、正規のartifactに脆弱性やバックドアが埋め込まれている場合の検証は不可能です。
publisherの正当性については、依存関係を定義する際に検証する必要があります。正規のartifactに脆弱性やバックドアが存在する場合には、ライブラリの更新が必要です。では、ライブラリの脆弱性が発見された場合、どのようにして迅速に検知するのが良いでしょうか？
GitHubを利用している場合、Dependabotを活用すると良さそうです。

Dependabotは、リポジトリ内の依存関係等を監視し、脆弱性を検知・アラートしてくれるBotです。DependabotはGradleにも対応していますが、直接記述している依存関係のみを参照し、推移的な依存関係は解決してくれません。そこで、GitHub ActionsのBuild with Gradleアクションを使用して依存グラフをDependabotに登録する方法がセッション内で紹介されていました。

サプライチェーン攻撃については知っていましたが、具体的な対処法や、Gradleにおける防御方法については知らなかったため、このセッションは非常に勉強になりました。artifactの改竄検知はセットアップに手間がかかるため、まずはDependabotを活用するところから始めようと思います。

たすけて！ ViewModel

次に、mhidaka氏によるたすけて！ViewModel / Help me! ViewModel というセッションです。

このセッションでは、主にComposeのViewModelにまつわる設計や責務の切り分けについての解説が行われました。

根本的な設計の原則として、単方向データフローの原則があります。これは、状態やイベントが流れる方向を単方向に限定し、双方向にしないという原則です。Composeにおいては、Compose UIからViewModelに対してイベントが送られ、ViewModelからCompose UIにデータが送られます。この原則により、Compose UIとViewModelの責務が明確に分離されます。

ViewModelはCompose UIに対して、UIStateという形でデータを提供します。このUIStateをCompose UIの唯一の信頼できる情報源として利用することで、より良いコードが実現します。また、ViewModel内部専用の状態をUIStateとは別に持ち、その内部状態をUIStateにマッピングすることで、さらに優れたViewModelを作成できます。
加えて、エラーハンドリングやテスト戦略についても詳しい解説がありました。

私にとって、このセッションを聞いて非常に印象的だったのは、「考え方がサーバーサイドとほとんど同じだ」という点です。
たとえば、エラーハンドリングにおいてエラーを分類し、その分類に基づいてモデル化するという工程が紹介されました。これはサーバーサイドでも重要な考え方です。エラーの分類により、サーバーが取るべき挙動や、そのエラーをどこでハンドリングするかが決まるからです。また、セッションの最後で述べられた「設計の原則は変化しない」という言葉がもっとも印象的でした。サーバーサイド開発においても、アーキテクチャは多種多様ですが、その基本となる設計の原則はほとんど変わっていません。このセッションを通じて、Androidアプリとサーバーサイドの設計が自然と似てくるのは、設計の原則が変わらないからだと再認識しました。

セッション後、Ask the Speakerの時間にmhidakaさんと直接お話をする機会がありました。そこで彼は、アプリ開発のトレンドとして「変更可能性」を重視する方向に向かっていると述べていました。これは、スマートフォンの性能向上や宣言的UI (Compose UI) の普及により、開発生産性を高めるアーキテクチャが採用されやすくなったためだそうです。さらに、テスタビリティについても言及がありました。UIStateという概念の導入により、ViewModelを「入力がイベント・出力がUIState」の単純な入出力で表現できるようになったため、ViewModelのテスティングが容易になったそうです。

クロスプラットフォームへの冒険： Kotlin Multiplatformでゲームエンジンを作る

次は、David氏によるクロスプラットフォームへの冒険： Kotlin Multiplatformでゲームエンジンを作るというセッションです。

このセッションでは、ゲーム開発の基本から、Kotlin Multiplatformを使用したゲームエンジンの作成に関する学びについて解説が行われました。

このセッションは英語のみのセッションでした。正直、英語のセッションを完全に理解する自信はあまりありませんでしたが、将来的に海外のカンファレンスにも参加したいという気持ちがあり、その第一歩として挑戦してみました。
結果としては、全体的に理解するのは難しかったです。ゲーム関連の仕組みの基礎やKotlin Multiplatformの基本については事前知識があったため、スライドを見ながら大まかな内容を理解することはできました。しかし、自分のあまり知らない部分や登壇者がとくに工夫した点については、十分に聞き取ることができず、内容を完全に把握できませんでした。

Kotlin Multiplatformでのゲーム制作は個人的に非常に興味深い内容ですので、後ほどアーカイブを字幕付きで視聴する予定です。来年までに英語のリスニング力を鍛え、再挑戦したいと思います。

Google Sign-inの移行から始めるCredential Manager活用

最後に、DeNAのTajimaさんによる Google Sign-inの移行から始めるCredential Manager活用というセッションです。

このセッションでは、Androidアプリで認証情報を扱うためのライブラリであるCredential Managerについて、Google Sign-inの移行に焦点を当てた解説が行われました。

まず、Tajimaさんのセッションに先立ち、DeNAのメンバーが多数応援に駆けつけており、セッション前は非常に和気あいあいとした雰囲気でした。これまでのソロ参加だったカンファレンスでは感じられなかった、楽しげな雰囲気が強く印象に残っています。

セッションの内容については、まず従来のGoogle Sign-inの実装方法が解説されました。Google Sign-inはGoogle Play servicesの一部のモジュールであり、Google Play services自体は1つのアプリとして動作します。各クライアントライブラリがIPC（プロセス間通信）を通じて、このサービスの機能を呼び出しています。

続いて、Credential Managerについての解説が行われました。Credential Managerは、さまざまな形式の認証情報を一元的に扱うためのライブラリです。ユーザーは複数の認証方法を1つのUIで扱えるようになり、開発者は統一されたAPIを通じて複数の認証方式をサポートできるため、非常に便利です。Android 14ではネイティブAPIが導入され、これをラップする形でJetpackのcredentialsライブラリが存在します。Android 13以下では、Google Play servicesの機能を利用してCredentialを扱う形となります。
Credential Managerは、アプリと認証を担当するCredential Providerの間の橋渡し役を担います。そのため、Credential Manager自体は認証情報を保持せず、Credential Providerはアプリが独自に実装することも可能です。

私自身、Google Play servicesの仕組みについてはまったく知らなかったため、この部分は非常に勉強になりました。また、Credential ManagerのAPIは非常に便利そうだと感じました。現状では、外部アカウントでログインする際にいったんブラウザを介す必要がありますが、アプリ内で完結する認証が可能になると、ユーザーにとっては大変便利です。一方で、開発者としては、複数の認証方式に対応する利便性が向上するものの、Android 13以下と14以上で挙動が異なるため、動作検証の手間が増える点を考慮する必要があると感じました。

アフターイベント

DeNAは9/18に、LINEヤフー株式会社さんと合同でアフターイベント「After DroidKaigi 2024」を開催しました。
このイベントでは、DeNA・LINEヤフーの各社員によるLT・パネルディスカッションを実施しました。
今回はオフライン・オンライン併用での開催だったのですが、オフラインでは約30人・オンラインでは約40人の方に参加いただきました！

このイベントで、私は「テストについてサーバーサイドと比べて考える」という題でLTを行いました。
私はDroidKaigi 2024を通して「Androidアプリのテストがしやすくなっている」・「Androidアプリのテストをしっかり書いていく」という空気を感じました。その中で、「テストしやすいアーキテクチャ」に関する考え方はAndroidアプリとバックエンドで共通しているように思いました。そこで、Androidアプリとバックエンドにおけるテストやテストしやすいアーキテクチャに着目して比較を行い、その共通点と異なる点について話しました。

他には、DeNAからはtetsukayさんによる、過去10年間のDroidKaigiとAndroidアプリ開発の振り返りを
LINEヤフーさんからは、Chigita Kazukiさんによる「CodeBugFixChallenge ブース準備の裏側」と、Ralphさんによる「13年にわたるLINE Androidのアーキテクチャの歴史とこれから」というタイトルのLTを行っていただきました。
偶然にもDeNA・LINEヤフーの両社からそれぞれ昔のAndroidアプリ開発を振り返るような内容のLTが行われました。自分はAndroidアプリ開発の歴史についてはほとんど知らなかったので、大変面白く参考になりました！

その後の懇親会では、参加者の方々と大変楽しくお話させていただきました。