GoogleのWebRTC Androidをビルドする機会があり、所々つまづいたので残しておきます。 参考URL https://webrtc.googlesource.com/src/+/main/docs/native-code/android/index.md 1.Ubuntu Linux環境の構築 VirtualBoxにUbuntuを導入する手順はよく転がっているので、詳細は割愛します。 仮想環境の構築 ビルド環境はLinuxのみがサポートされているので、私の場合はMacにVirtualBoxをインストールしUbuntu Linuxの環境を構築しました。 注意点としては、まずストレージのサイズですがデフォルトの(確か)10GBだと小さすぎるので64GBのストーレジを割り当てたことと、ビルド速度に影響するCPUの個数も4個割り当てました。１個だとビルド時間がかなり長くなります。メインメモリも8GB割り当てました。 Ubuntu Linuxのインストール Ubuntuは言語を日本語でインストールすると画面にウインドウが収まらなくてボタンが押せなかったので言語をEnglishで最小構成（Minimal installation）インストールしました。Englishならギリギリボタンが押せます。 800x600のサイズで画面が始まるので文字が小さいけど頑張ってインストール。 インストール後はSettings -> Display からいい感じの大きさに変更しました。 あとソースのダウンロードなど結構時間がかかるのでSettings -> Power SavingでBlank ScreenをNeverにして画面にロックがかからないようにしました。 2.Chromium depot toolsをインストールする AppRTCをビルドする時に利用するコマンドが使えるようにUbuntu LinuxにChromium depot toolsをインストールします。 UbuntuでTerminalを起動します gitのインストール gitが入っていなかったのでインストールします $ sudo apt install git Chromium depot toolsのソースを取得 適当なところにディレクトリを作って $ git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git パスを通す $ export PATH=/home/atsuo/Source/depot_tools:$PATH 3. webrtc_androidのビルド gccを使うのでインストールしておく $ sudo apt install gcc 適当なところにディレクトリを作成して $ fetch --nohooks webrtc_android $ gclient sync ↑結構時間がかかります。 2012/10/14時点のソースだとdebugビルドすると通話切断時にクラッシュする問題があるのでreleaseビルドします ビルド！！ $ cd src $ gn gen out/Release --args='target_os="android" target_cpu="arm64" is_debug=false' $ autoninja -C out/Release AppRTCMobile out/Release/apks/AppRTCMobile.apk ↑ apkファイルができているのでスマホにインストールして https://appr.tc/ とスマホとブラウザ間でビデオ通話できます。

対象 コルーチン全く知らないんだけど、一緒に勉強してくれる人がいない人 ひとりコードラボ会 ZOZOさんが、チームの開発力向上のためにコードラボ会をやっているとの情報を聞いたので、自分もやってみようと思いました。 コードラボは、Google様が提供している教育コンテンツのことです。 今まで、やってこなかったのですが、現場の方も活用しているということは、情報の質が高いのかなと思い、チラ見したらそんな感じしたので、習慣化しようと思いました。 コルーチンの概要 「コルーチンの概要」というコンテンツをやろうと思います。 超入門レベルな解説いきます。 スレッドとは fun main() { println(a()) println(b()) println(c()) } fun a() = "a" fun b() = "b" fun c() = "c" Androidプログラミング（多分他もそう）は、基本的にメインスレッド君が一人で処理を行っています。 スレッドとは、プログラミングにおいて処理の始まりから終わりまでの一連を一塊とした単位のことです。 が、まぁスレッドという人が処理していると捉えたほうが、イメージ化しやすいと思います。 上記のような感じの処理があるとすると、逐次処理なので a -> b -> c の順に処理されていくわけです。 仮に一つ一つの処理に、1ミリ秒かかるとすると計3ミリ秒となります。 しかし、bが1時間かかるとしましょう。 fun main() { println(a()) println(b()) println(c()) } fun a() = "a" fun b() = { // 何かしらで1時間かかる重い処理 } fun c() = "c" } メインスレッドくんが、一人で処理することになるため計1時間と2ミリ秒かかってしまいます。 実際のアプリでは、c　にViewの更新があると画面が謎に固まるというウザい現象になり、ユーザーが離れてしまいます。 それに関しては、もう一人の分身を作ってそいつにやらせるが解決策です。 メインスレッドが「本体」で、他のスレッドが「分身」というイメージです。 Threadインスタンスを生成することで、分身の出来上がりです。 ラムダ内に、処理を書けば分身がそれをやってくれます。 これによって、bが処理されるまで、c処理が待ち状態になること（俗に言うブロッキング）がなくなります。 役割分担はこんな感じ。 本体： a -> c 分身： b fun main() { println(a()) Thread { println(b())}.start() println(c()) } fun a() = "a" fun b() = { // 何かしらで1時間かかる重い処理 } fun c() = "c" } また、分身は複数作ることができます。 出力結果も添付されているので、コードラボの方をコピペしやす。 for文で分身を作るのを３回回している感じです。 fun main() { val states = arrayOf("Starting", "Doing Task 1", "Doing Task 2", "Ending") repeat(3) { Thread { println("${Thread.currentThread()} has started") for (i in states) { println("${Thread.currentThread()} - $i") Thread.sleep(50) } }.start() } } そして、出力結果は下記のようになるみたいです。 currentThread()は、スレッドの詳細を出力するので、この場合ですと [番号、優先度、スレッド]だと思います。（間違っていたらすまぬ） Thread[Thread-0,5,main] has started Thread[Thread-1,5,main] has started Thread[Thread-2,5,main] has started Thread[Thread-1,5,main] - Starting Thread[Thread-0,5,main] - Starting Thread[Thread-2,5,main] - Starting Thread[Thread-1,5,main] - Doing Task 1 Thread[Thread-0,5,main] - Doing Task 1 Thread[Thread-2,5,main] - Doing Task 1 Thread[Thread-0,5,main] - Doing Task 2 Thread[Thread-1,5,main] - Doing Task 2 Thread[Thread-2,5,main] - Doing Task 2 Thread[Thread-0,5,main] - Ending Thread[Thread-2,5,main] - Ending Thread[Thread-1,5,main] - Ending このように、Thread1 -> Thread2-> Thread3 -> と順々に処理されているのではなく、分身が各々処理を進めているのがわかると思います。 これが、スレッドの特徴です。 うまく活用することで、処理の時間を短くしたり、同時にいろんな処理を行うことができます。 スレッドの課題 物事には良い面もあれば、悪い面もあるので、スレッドにもいくつか問題点があります。 OS消費が多め スレッドを作成や切り替えること諸々消費が激しいです。 アプリは、最低限一秒間に60フレームのスピード感で更新が行われます。 スレッド管理が多すぎると応答性が悪くなってしまう場合があります。 予期せぬ動作が起きることも マルチスレッドの仕組みがややこしいので、ふんわりとした説明になります。（やはり、エンジニアにCSの教養は必要なわけですｗ） プロセッサという、CPUに命令を指揮する部分が分身に処理を分け与えても、そいつが処理を始めるタイミングや途中で中断するタイミング等は制御不能なんです。 そのため、スレッドを直で扱おうにも想定した挙動にすることは難しいという問題点があります。 コードラボには、その例が掲載されています。 fun main() { var count = 0 for (i in 1..50) { Thread { count += 1 println("Thread: $i count: $count") }.start() } } 下記にてスレッド番号を見ると分かるように、ランダムな処理になってしまいます。 これが、予期せぬ動作が起き得るという問題点です。 Thread: 50 count: 49 Thread: 43 count: 50 Thread: 1 count: 1 Thread: 2 count: 2 Thread: 3 count: 3 Thread: 4 count: 4 Thread: 5 count: 5 Thread: 6 count: 6 Thread: 7 count: 7 Thread: 8 count: 8 Thread: 9 count: 9 Thread: 10 count: 10 Thread: 11 count: 11 Thread: 12 count: 12 Thread: 13 count: 13 Thread: 14 count: 14 Thread: 15 count: 15 Thread: 16 count: 16 Thread: 17 count: 17 Thread: 18 count: 18 Thread: 19 count: 19 Thread: 20 count: 20 Thread: 21 count: 21 Thread: 23 count: 22 Thread: 22 count: 23 Thread: 24 count: 24 Thread: 25 count: 25 Thread: 26 count: 26 Thread: 27 count: 27 Thread: 30 count: 28 Thread: 28 count: 29 Thread: 29 count: 41 Thread: 40 count: 41 Thread: 39 count: 41 Thread: 41 count: 41 Thread: 38 count: 41 Thread: 37 count: 41 Thread: 35 count: 41 Thread: 33 count: 41 Thread: 36 count: 41 Thread: 34 count: 41 Thread: 31 count: 41 Thread: 32 count: 41 Thread: 44 count: 42 Thread: 46 count: 43 Thread: 45 count: 44 Thread: 47 count: 45 Thread: 48 count: 46 Thread: 42 count: 47 Thread: 49 count: 48 また、複数のスレッドを走らせると同じメモリ領域に同時アクセスなんかも起こりうるので、クラッシュの原因になります。 さらに、スレッドが順不同に処理されることによるバグは再現はほぼできないので、クラッシュの原因を特定するのは極めて困難です。 スレッドを手動で操作するのは良くないんですね。 コルーチンとは そんなマルチスレッドによる問題を回避するためにコルーチンを使います。 まずは、簡単にコルーチンのメリデメについて解説していきます。 メリット 保存 分身が処理しているのを一旦停止して、保存することが可能です。 それにより、途中から別のスレッドで処理を再開することも出来ます。 これのことを通称「軽量」と言われています。 まぁ、確かにスレッド間で処理の持ち運びができるので、軽いイメージはある。（けど、いきなり軽量って言われても？ってなる。） コルーチンは特殊な分身（≒スレッド）です。 厳密にはスレッドではないが、役割としてはスレッドと同じ。 短い 短いコードで簡潔に書く事が出来ます。 節約 構造化された同時実行とやらでメモリリークの削減になる（ここの掘り下げ先延ばし） 相性 Jetpackライブラリのと相性が良いです。 コルーチンをサポートしているので！ デメリット 書き方が色々あり過ぎる 調べていて、色んな書き方があり混乱する瞬間がいくつかあった笑。 スレッドの操作は簡単にできるけど、どれが良い書き方なのか結局分からない。 コルーチンの使い方 build.gradle dependencies { implementation("org.jetbrains.kotlinx:kotlinx-coroutines-android:1.3.9") } 最初の方に書いた処理をコルーチンで走らせると、下記のようになります。 fun main() = runBlocking { launch { // このスコープ内で、新しい分身（コルーチン）が作成され、処理が走る。 b() } // 下記がコルーチンのメインスレッド a() c() } fun a() = "a" fun b() = { // 何かしらで1時間かかる重い処理 } fun c() = "c" } launch 「作成」 新しい分身（コルーチン）を作成を行います。 launchメソッドの裏コードはこんな感じです。 blockプロパティにsuspendキーワードがついているので、スコープ内の処理を一時中断できる事が分かります。 fun CoroutineScope.launch { context: CoroutineContext = EmptyCoroutineContext, start: CoroutineStart = CoroutineStart.DEFAULT, block: suspend CoroutineScope.() -> Unit } runBlcking 「中断」 こちらもコルーチンの生成を担っているのですが、コルーチンを用いてないコードと用いているコードの仲介役を担います。 このスコープ内(CoroutineScope)でないとlaunchを正しく呼び出すことが出来ません。 とはいえ、runBlockingはスコープ内の処理が終わるまで、現在のスレッドがブロッキングされます。 アプリケーションスコープで使われるので、実用性は皆無ないようです。（なぜサンプルで使った！？） その他 Dispathers 「決定」 どのスレッド（分身）で実行するか決定します。 GlobalScope 「全体」 アプリ単位でコルーチンを作成するためのものです。 メモリリークに繋がるので、使いどころに気をつける必要があります。 不明点 さくっと終わらせたいので、一先ずこのくらいにします。 解消できなかった、不明点はこちら。 suspendについて 構造化された同時実行について ざっくりとではあるが、スレッドの仕組み（読み進めていく中で、自分が思っているスレッドのイメージと合ったり合わなかったりで違和感が残った。） 終わりに スレッドの仕組みがいまいち良く分からないので、こんなもんかなという感じで書きました。 初めてのコードラボですが、とっても質の高い情報で読みごたえがありました。 これを継続させていけば、確かにAndroidの知識は底上げできるなと思います。 今回は、あくまでも概要でコードを書くテーマではなかったので、次はコルーチンを書き書きするのをやりたいと思います。 参考

株式会社ゆめみの Android の採用コーディング試験を公開しました 会社の採用試験どうしよう、、と悩んでいる採用担当の方がいましたら、ぜひご活用ください レビューできる人がいないという場合には、ぜひ弊社までご相談いただけたらと思います。 なんで公開したの？ 主に応募のハードルを下げるのが狙いです どんな試験なのか分かっているだけで、だいぶ気が楽になりますよね また、逆に無茶な応募が減るということもあるのではとも考えています。 どんな試験？ ざっくり説明すると メチャクチャなコードを改善してください というものです 詳しくはリポジトリの README をご覧ください。 ※ 新卒か中途かによって必須課題が変わる点にはご注意ください。 公開しちゃって大丈夫なの？ 誰かが良い解答を公開したら、それを真似すればいいんじゃ？ そもそもどれが良い解答なのかを判断しなければなりません。 どれが良い解答なのか判断できたら、合格で何も問題ありません あるあるかもしれませんが、丸パクリするような人に限って、あまり良くないコードをパクっていることが多いイメージです。 あと、実はちょっとした工夫をしているので、おそらく大丈夫です。 事前に解いていて、Git の履歴を改竄して期限内に提出とかできるんじゃ？ 最終的にできるようになっているのであれば問題ありません。 逆に Git 操作がきちんとできるんだなと好印象です。 試験の解答期限の１週間というのは、応募者に無理をさせないためのものです。 できる人であれば、１日で試験完了して合格しています。 試験で見ているところは？ おかやまん個人 として見ているところを大まかな項目ごとに書いていきます 試験内容に明示されている内容を見るのは当たり前なので、他のところだけピックアップします。 さすがに全ては書ききれませんが、少しでも参考になれば幸いです。 README について 環境構築するために必要な情報が記載されているか AndroidStudio の canary 版でしか動作しなかったり、特定のスクリプトを実行しなければ動作しなかったり、、、 アプリを動作させるのに特殊なことをしなければならない状態であれば、きちんと記載されているか確認します。 各 Flavor の役割が記載されているか 特定の Flavor では固定のモックデータを扱うなど、不具合なのか意図した動作なのか判断できない場合があります。 余計な確認コストを削減するためにも記載しておきましょう。 Git について 適切に .gitignore が設定されているか 他のメンバーの環境でビルドができなくなってしまったり、ビルドの度にファイルの変更が発生してしまったり、、、 きちんと設定していないとそもそも開発がストップしてしまうため、これができていないと厳しいです。 開発するときは、何を管理対象にするかしないのかをきちんと確認しましょう。 意味のある粒度でコミットを作成しているか 意味のある粒度でコミットを作成していれば、リバートコミットで範囲を絞って元に戻したり、チェリーピックでコミットを丸ごと別ブランチに移植したりすることができます。 粒度が小さければ小さいほどいいというわけではありませんが、粒度が大きいよりはメリットがあるという感覚です。 たまに 全てを１つのコミットにまとめてきた！ という方がいらっしゃいますが、開発プロセスや意図が伝わりづらくレビューするのが大変になるので、やめていただけると幸いです 笑 チーム開発する上で、他のメンバーやレビュアーのことを考えている方って、それだけでステキですよね 適切なブランチ運用 様々なブランチ運用がありますが、開発を進めるにあたって問題がなければどれでも大丈夫です 課題のチェック項目ごとにブランチを切って、GitHub のプルリクエスト機能を利用して修正理由を明確に記載していると好印象です。 たまに、プルリクエスト機能を利用してるけど、説明に何も書いていない なんちゃってプルリクエスト をしている方がいますが、それではあまりプルリクエストを出す意味がありません。。（ GitHub Actions を利用しているとかであれば話はちょっと変わってきます） ブランチ運用例 Git flow GitHub flow GitLab Flow ライブラリについて 追加・更新・削除時の影響をきちんと確認しているか ライブラリを追加・更新・削除すると、勝手に他のライブラリのバージョンが上がったり下がったりしてしまうことがあります。 リリースノートを確認したり、変更前後の依存関係を比較したりすることをオススメします。 また、これまでコードレビューをしてきた経験上、プロガードの設定が漏れていることが多いです。 試験のコードは、リリースビルドで難読化を有効にしているので要注意です 不要なものを記述していないか 未使用のライブラリを記述しないというのは当たり前ですが、きちんと implementation debugImplementaion testImplementaion androidTestImplementaion などの使い分けができているかは重要です。 特に、リリースビルドにデバッグ用のライブラリが入っていないかは要確認です。 正しく扱えているか バージョンによって挙動が変わったりするため、利用しているバージョンのドキュメントを確認して実装しているか確認します。 正直なところ、確認するのは骨が折れます。。 いろいろなことが知れる機会だと思い、自分の心を鬼にして確認しています 例えば、JSON を扱うときに利用される kotlinx.serialization の ignoreUnknownKeys という設定についてです。 true に設定すると、以下のようにProject クラスには存在しない launguage というものが JSON データにあった場合、例外を発生させずに無視してデシリアライズを続行します。（デフォルトでは false ） val format = Json { ignoreUnknownKeys = true } @Serializable data class Project(val name: String) fun main() { val data = format.decodeFromString<Project>(""" {"name":"kotlinx.serialization","language":"Kotlin"} """) println(data) } このような動作を把握していないと API が更新された時に、アプリがクラッシュしたり、期待する動作をしなくなったりしてしまいます。 ライブラリを導入する際は、くれぐれもお気をつけください！ コードについて 基本的に、試験の課題を確認していただけたら分かると思います。 ですが、せっかくなので少しだけピックアップします。 読みやすいコードになっているか 自分がこれまでに見てきた中でも最高にイケていないコードを、かなり省略してご紹介いたします。 ※ ゆめみではなく前職のときに遭遇しました var _a = mapOf("Emi" to 3, "Taro" to 12, "Takuya" to 35) var _b: Any? = null fun main() { _b = mutableListOf<Any>() (_b as MutableList<Any>).add(_a["Takuya"] as Any) (_b as MutableList<Any>).add(_a["Emi"] as Any) (_b as MutableList<Any>).add(_a["Taro"] as Any) _b = (_b as MutableList<Any>)[0] as Int - ((_b as MutableList<Any>)[1] as Int + (_b as MutableList<Any>)[2] as Int) println(_b!!) } みなさんは、最後に何が表示されるかパッと分かりますか？ 私は分かりません 笑 実際には、こんなコードが１つのファイルに１万行ほど書かれており、震えが止まりませんでした。 サービスやアプリを長く提供し続けるためにも、簡潔性・可読性・保守性の高いコードを書けることは非常に重要です。 テストを書きやすいコードになっているか テストがあるに越したことはありませんが、無理くり書いたテストコードは保守性を大きく損ねる危険性があるため要注意です。 まずは、責務を分割したり、モックと簡単に差し替えられるような構成にしたりして、テストを書きやすくすることをおすすめします。 UI について 画面回転や端末の画面サイズ、フォントサイズ、ダークモードのことを考えているか Android アプリ開発者の宿命と言っても過言ではありません。 画面回転するとダイアログが２つ表示されてしまう 端末によって大幅にレイアウトが崩れてしまう フォントサイズを大きくすると、文字が見切れてしまう ダークモード時に文字が見づらくなってしまう あるあるですよね。。 この辺りのこと対応できていると好印象です。 プレビューで確認できるようしているか xml では tools 属性、Jetpack Compose では Preview アノテーションを利用しているか確認します。 アプリを実行しなくてもレイアウトの確認ができると、開発効率は想像以上に上がります。 初めの段階からプレビューできるようにしておくのをおすすめします。 ネストを浅くしているか ネストが深いと、可読性やパフォーマンスが低下してしまいます。 たまに、１つの ConstraintLayout だけで表現できる箇所を、ConstraintLayout を複数ネストさせて表現してきてしまう方がいらっしゃるのでご注意ください。 ConstraintLayout は、非常に便利ですので一通りの機能を試してみることをおすすめします。 その他 エラー発生時にどのようにしているか エラーを握りつぶして、ユーザーが何も分からない状態になっているのは論外です。 場合によっては、エラーをキャッチせずにアプリを落とす方が良いこともありそうです。 理想的には、エラーが発生したことや発生原因をユーザーに伝え、その後ユーザーがどうすればいいかまで誘導できればステキです どのくらい自動化しているか 自動化できるものってたくさんありますよね。 コードの整形、モックデータの生成、ビルド、テスト、デプロイ、、などなど GitHub Actions や Firebase などのおかげで、この辺りも比較的簡単に自動化できるようになってきました。 しかし、コーディング試験で一時的なデプロイ環境を用意して、デプロイまで自動化している猛者には、さすがにビビりました あとがき 以上、ゆめみの Android の採用コーディング試験の紹介でした。 ゆくゆくは英語などにも対応して、海外の企業でも利用できるように改善していく予定です。 一生懸命考えて作成した試験ですが、まだまだ改善の余地はあると思います。 何かお気づきの際には、優しくご教示いただけますと幸いです。 教材として、採用試験として、たくさんの方にご活用していただけたらと思いますので、ぜひ拡散お願いいたします！ 同じ会社の iOS の記事

はじめに 仕事でAndroidアプリにオープンソースライセンスを表示させる必要があり、初めてクックパッドさんのlicense-tools-pluginを使用しました。 今後も使用する機会があるかと思い、導入方法をまとめました。 license-tools-pluginとは クックパッドさんが公開しているプラグインで、以下の機能が提供されています。 - yamlを使ったオープンソースライセンスの管理 - ライセンス追記漏れのチェック - ライセンス一覧のhtmlの作成 開発環境 PC：MacBook Pro OS：macOS BigSur Android Studio：Arctic Fox 2020.3.1 license-tools-pluginの導入方法 ※今回はAndroid開発でよく使われるライブラリをいくつか追加し、出力したhtmlファイルをwebViewに表示させる方法について記載いたします。 1.プラグインを追加 build.gradle(project)に以下のコード上の①〜③を追記します。 追加②に関しては、最新のバージョンをこちらから確認して置き換えてください。 build.gradle(project) buildscript { repositories { google() mavenCentral() //追加①　ここから maven { url 'https://plugins.gradle.org/m2/' } //ここまで } dependencies { classpath 'com.android.tools.build:gradle:4.2.2' classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:1.5.30" classpath 'gradle.plugin.com.cookpad.android.plugin:plugin:1.2.8' //追加② } } task clean(type: Delete) { delete rootProject.buildDir } apply plugin: "com.cookpad.android.plugin.license-tools" //追加③ build.gradleへの記述が終わったら、画面上部にあるSync Nowを押して同期します。 2.ymlファイルを作成 Android StudioのTerminalに以下のコマンドを入力し、yamlファイルを作成します。 ./gradlew updateLicenses 実行が完了すると、app直下にlicenses.ymlというyamlファイルが追加されます。 licenses.ymlの内容は以下のようになっています。(一部を抜粋) licenses.yml - artifact: androidx.activity:activity:+ name: activity copyrightHolder: #COPYRIGHT_HOLDER# license: The Apache Software License, Version 2.0 licenseUrl: http://www.apache.org/licenses/LICENSE-2.0.txt url: https://developer.android.com/jetpack/androidx/releases/activity#1.2.4 - artifact: androidx.annotation:annotation-experimental:+ name: annotation-experimental copyrightHolder: #COPYRIGHT_HOLDER# license: The Apache Software License, Version 2.0 licenseUrl: http://www.apache.org/licenses/LICENSE-2.0.txt url: https://developer.android.com/jetpack/androidx/releases/annotation#1.1.0 - artifact: androidx.annotation:annotation:+ name: annotation copyrightHolder: #COPYRIGHT_HOLDER# license: #LICENSE# licenseUrl: http://www.apache.org/licenses/LICENSE-2.0.txt url: https://developer.android.com/jetpack/androidx/releases/annotation#1.2.0 - artifact: androidx.appcompat:appcompat-resources:+ name: appcompat-resources copyrightHolder: #COPYRIGHT_HOLDER# license: #LICENSE# licenseUrl: http://www.apache.org/licenses/LICENSE-2.0.txt url: https://developer.android.com/jetpack/androidx/releases/appcompat#1.3.1 // ライブラリの数によってはかなり長くなります ここから少し面倒ですが、#COPYRIGHT_HOLDER#や#LICENSE#となっている箇所を調べて手動で編集します。 yamlファイル内のartifactやlicenseUrlを1つ1つ検索し、GitHubなどから情報を得ることができます。 （Androidの標準ライブラリは、The Android Open Source Projectと記載します。） 今回の場合ですと、以下のように編集します。 licenses.yml - artifact: androidx.activity:activity:+ name: activity copyrightHolder: The Android Open Source Project license: The Apache Software License, Version 2.0 licenseUrl: http://www.apache.org/licenses/LICENSE-2.0.txt url: https://developer.android.com/jetpack/androidx/releases/activity#1.2.4 - artifact: androidx.annotation:annotation-experimental:+ name: annotation-experimental copyrightHolder: The Android Open Source Project license: The Apache Software License, Version 2.0 licenseUrl: http://www.apache.org/licenses/LICENSE-2.0.txt url: https://developer.android.com/jetpack/androidx/releases/annotation#1.1.0 - artifact: androidx.annotation:annotation:+ name: annotation copyrightHolder: The Android Open Source Project license: The Apache Software License, Version 2.0 licenseUrl: http://www.apache.org/licenses/LICENSE-2.0.txt url: https://developer.android.com/jetpack/androidx/releases/annotation#1.2.0 - artifact: androidx.appcompat:appcompat-resources:+ name: appcompat-resources copyrightHolder: The Android Open Source Project license: The Apache Software License, Version 2.0 licenseUrl: http://www.apache.org/licenses/LICENSE-2.0.txt url: https://developer.android.com/jetpack/androidx/releases/appcompat#1.3.1 // ライブラリの数によってはかなり長くなります 全て編集が完了したら、Android StudioのTerminalに以下のコマンドを入力し、yamlファイルの確認をします。 ./gradlew checkLicenses エラーが発生しなければ問題なくyamlファイルが作成されています！ 3.ライセンス一覧を作成 Android StudioのTerminalに以下のコマンドを入力し、htmlファイルを作成します。 ./gradlew generateLicensePage 実行が完了すると、app直下にlicenses.htmlというhtmlファイルが追加されます。 4.ライセンスをアプリに表示 Assetsフォルダを作成し、先ほど追加されたlicenses.htmlを格納します。 htmlファイルをWebViewで表示するために、activity_main.xmlにWebViewを追加します。 activity_main.xml <?xml version="1.0" encoding="utf-8"?> <androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android" xmlns:app="http://schemas.android.com/apk/res-auto" xmlns:tools="http://schemas.android.com/tools" android:layout_width="match_parent" android:layout_height="match_parent" tools:context=".MainActivity"> <WebView android:id="@+id/web_view" android:layout_width="match_parent" android:layout_height="0dp" android:layout_margin="16dp" app:layout_constraintBottom_toBottomOf="parent" app:layout_constraintEnd_toEndOf="parent" app:layout_constraintStart_toStartOf="parent" app:layout_constraintTop_toTopOf="parent"> </WebView> </androidx.constraintlayout.widget.ConstraintLayout> MainActivity.ktには、WebViewにassetsフォルダ内のhtmlファイルを表示するよう記載します。 MainActivity.kt class MainActivity : AppCompatActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) val webView = findViewById<WebView>(R.id.web_view) webView.loadUrl("file:///android_asset/licenses.html") } } ここまでできたらアプリを実行してみましょう！ WebView内にオープンソースライセンスを表示することができました！ このままでもいいですが、URLが長いと横スクロールで見ることになり少し見づらい問題がありました。 修正したい場合は、htmlファイルに以下を追加します。 すると、横幅に合わせて改行されるめ、横スクロールをなくすことができます。 a { overflow-wrap: break-word; } その他 アプリを作成する上で、ライブラリを追加した際は./gradlew checkLicensesコマンドを実行することで差分が取れます。 差分をコピーし、現在の licenses.ymlファイルにペーストします。 以降は初回時と同様に#COPYRIGHT_HOLDER#や#LICENSE#を編集し、再度コマンドを実行しエラーが無いかを確認します。 htmlファイルも再度./gradlew generateLicensePageコマンドで作成すれば、オープンソースライセンスを更新できます。 参考文献 GitHub: https://github.com/cookpad/LicenseToolsPlugin クックパッド開発者ブログ: https://techlife.cookpad.com/entry/2016/04/28/183000

突然通信が途絶することがある TPLINKのルーターを使用しているときに突然通信が途絶（WIFIの接続は生きているが、外部との通信が突然途切れる、特定のクライアントのみで他のクライアントでは異常なし）することが頻繁に起きるので調べてみました。 シスログを見てみよう DoS攻撃保護に関するエントリーが見つかったら、ファイアウォールの設定が原因と見られる。 もしDoS攻撃保護が原因でインターネットとの通信が遮断されている場合は下記のリストにホストが登録される。 ファイアウォールの設定ーDoS攻撃保護 高に設定された状態で通常の使用をしている最中にYouTubeの再生が途中で止まったり、VPNが途切れたり、色々と不具合が起きていたのですが、どうやらこの設定が原因でした。たしかに、問題が起きている最中はリストに該当のホストが登録されている状態が見えました。 中に下げると不具合はとりあえず今の所起きていません。（問題があれば低まで下げる必要がある・・・？） ※追記　中でも発生したので現在低まで下げました。 レベルの設定 ここでフィルターされるパラメーターの調整ができるようです。最近のスマートフォンは高性能になったので、1秒あたりに送信するパケット数が多いのかな・・・。