内容
M1 MaxなMacBook Proが我が家に届いた!ということで早速セットアップを行ったところ、プロジェクトがKaptのところでビルドエラーになる。
対応
参考URLによると、Roomのところでエラーになるらしい。ということでRoomのバージョンを最新の 2.4.0-beta02
に変更したところビルドが通った。
備考
自分のプロジェクトではたまたまRoomがエラーになっただけだったけど、他にもあるのかもしれない
M1 MaxなMacBook Proが我が家に届いた!ということで早速セットアップを行ったところ、プロジェクトがKaptのところでビルドエラーになる。
参考URLによると、Roomのところでエラーになるらしい。ということでRoomのバージョンを最新の 2.4.0-beta02
に変更したところビルドが通った。
自分のプロジェクトではたまたまRoomがエラーになっただけだったけど、他にもあるのかもしれない
先日サポートしているアプリにお問い合わせがあり、内容とは別にそのユーザーの端末のビルド番号が 機種ID.バージョン test-keys
となっていた。機種名は一応伏せるがGoogleのPixel端末などではなくいわゆる中華端末である。
ビルド番号にtest-keys
がつくのはAOSPなどで独自にOSビルドをし、署名をしていない状態のアプリケーションのことである。
Android ツリーは build/target/product/security にテストキーを含みます。make を使用して Android OS イメージをビルドすると、テストキーを使用してすべての .apk ファイルに署名します。テストキーは一般に知られているため、だれでも .apk ファイルに同じキーで署名できることになり、そのままでは OS イメージに組み込まれているシステムアプリの置き換えやハイジャックにつながる可能性があります。そのため公開またはデプロイする Android OS イメージには、自分だけがアクセスできる特別なリリースキーのセットを使用して署名する必要があります。
カスタム Android ビルドの確認 デバイスがルート化されているかどうかを確認するだけでなく、テストビルドやカスタム ROM の兆候を確認することも役に立ちます。これを行う方法のひとつは、BUILD タグに test-keys が含まれているかどうかを確認することです。これは一般的にカスタム Android イメージを示します。Google Over-The-Air (OTA) 証明書の欠落はカスタム ROM のもうひとつの兆候です。出荷版の Android ビルドでは、OTA アップデートに Google の公開証明書を使用します。
なのでこの端末は署名がなされおらず、一見通常の中華端末としてビルドされているようである。
自分でRoot化したりOS入れ直したりしている人なら(悪事に使ってない限り)特に問題はない。
ただしこれが中古で安く購入した端末だったりした場合には意味が変わってくる。キーロガーが仕掛けられていたり、
パスワードや位置情報などが不正に情報が送信されているような恐れも出てくる。
(ただ本当に悪意のあるハッカーなら一眼でわかるような情報は残さない気もするが)
Playプロテクトはインストールされたアプリに対するチェックだから無効な気がする。 この状態でPlay Storeアプリを使うことや課金は出来るのだろうか?
自分の端末でもないし、現時点でこれ以上調べられることはないが、
お問い合わせをしてくれたユーザーはtest-keys
が付いていることに気づいていないかもしれないので不安がある。
仕事上テスト端末として結構な数の中古端末を買っていたので一応全部のビルド番号を再確認した(問題なし)。 今後は購入時に店頭の起動チェックで必ずビルド番号の欄を見るように気をつけよう。
ちなみに自分はAndroidのサイトから開発版のAndroid12をPixel 4にインストールして使っていたが、こちらには署名済みらしくtest-keys
はついていなかった。
HiltViewModelを使うとActivity起動時に使われるIntentパラメータの値も下記記事と同様に ViewModelのSavedStateHandleにセットされていることを確認。
Fragment 1.2.0 以降で利用可能になった SavedStateHandle
を試しに書いてみたら いつもFragmentからrequireArguments()で取得してた内容が
savedStateHandleの中に入ってたという話。
コンストラクタに引数を追加する。これだけ。ViewModel名はお好みで
class SavedStateViewModel(private val state: SavedStateHandle) : ViewModel() { ... }
Fragmentはこんな感じ。 newInstance(userId)
でMainFragmentを引数付きで起動するイメージ。
class MainFragment : Fragment() { val vm: SavedStateViewModel by viewModels() companion object { fun newInstance(val userId: Int) : MainFragment = MainFragment().apply { arguments = Bundle().apply { putInt("userId", userId) } } } }
ViewModel側でおもむろに使用する。getLiveData()を使えばLiveDataとして使うこともできる。
class SavedStateViewModel(private val state: SavedStateHandle) : ViewModel() { init { val userId: Int = state.get(userId)!! } }
これで一覧をリクエストする処理なんかをViewModel側で完結して書けるようになったと思う。
Hiltを使っていても関係なく、特に特別な記述も必要なかった。
本当はSavedStateHandleを調べようとし始めたばかりだったんだけど、セットもしてないのに値が入っててびっくりしたのでとりあえず。
Fragmentに渡ってきた引数をViewModelにどう渡すかで試行錯誤してたのでこれは助かる。
もうちょっと色々できると思うので引き続き調べてみよう。