最近パッケージの管理方法が変わったみたいなのでまとめてみた。

事前準備(端末のシェルへのアクセス

adbのインストール

Arch Linuxならandroid-toolsをインストールする。

$ sudo pacman -S android-tools

端末を開発者モードにする

例えばこちらを参照

母艦からシェルにアクセスする

公式ドキュメントを参照。
AndroidデバイスをUSBでコンピュータに接続し以下のコマンドを実行する。
途中で端末に「リモートアクセスを許可しますか?」と表示されるためOKを押す必要がある。

$ adb devices
$ # 接続されている端末のシリアル番号が表示される
$ adb -s シリアル番号 shell

もしくは以下のように直接コマンドを実行することもできる。(下の例では使用できるコマンドの一覧を表示)

$ adb -s シリアル番号 shell ls /system/bin

パッケージマネージャ

pm および cmd packageコマンドを使うことになります。

例

Google Playからインストールしたパッケージの一覧を取得する

adb -s シリアル番号 shell cmd package list packages -i | sed -ne '/installer=com\.android\.vending/p' | sed -e 's/^package:\(.*\)  installer=.*$/\1/'

パッケージをインストールさせるためにGoogle Playを開く

adb -s シリアル番号 shell am start-activity 'market://details?id=パッケージ名'

最初に

サポートライブラリの後任となる AndroidX ライブラリですが、
マイナーバージョンが上がると内部的なクラス関係がけっこう変更されています。

標準ライブラリと言っても良い AndroidX ですが 1.1.0 では以下のアップデートが行われました。

1.0.0 以降の重要な変更

２項目の AppCompatActivity について

この中の AppCompatActivity についてピックアップします。

AppCompatActivity が Fragment 1.1.0 を介して、
Activity 1.0.0 の ComponentActivity から推移的に拡張されるようになりました。

推移的に拡張... ←どうもイメージ掴みにくいですね。

元々 appcompat は、フラグメント機能を持つ androidx.fragment:fragment に依存していました。

こちらの内部バージョンが上がり、
そのフラグメント内で新たに androidx.activity に依存するように なりました。

	androidx.fragment	androidx.activity
appcompat:1.0.0	1.0.0	-
appcompat:1.1.0	1.1.0	1.0.0

なにが変わるのか

AppCompactAcitivty の継承関係 に変更が入りました。

【1.0.0】
AppCompatActivity
 +- androidx.fragment.app.FragmentActivity
  +- androidx.core.app.ComponentActivity
   +-  android.app.Activity

【1.1.0】
AppCompatActivity
 +- androidx.fragment.app.FragmentActivity
  +- androidx.activity.ComponentActivity
   +- androidx.core.app.ComponentActivity
    +- android.app.Activity

1.1.0 では androidx.activity.ComponentActivity が新規に追加され、FrameActivity のスーパークラスのパッケージ自体が別物になっています。

これにより、
・サードパーティ製のライブラリが appcompat:1.1.0
・自分のプロジェクトを appcompat:1.0.0
という状況で開発を行っていると... ライブラリ側にandroidx.activity.ComponentActivity を参照するコードがあると、ビルドが通らなくなります。

ライブラリ側から見たら、aar 作成時には認識していたクラスが「いざリンクしよう！」としたら無くなったので当然ですね。

対策は？

この場合、サポートライブラリ時代と同じように

configurations.all {
    resolutionStrategy.eachDependency { DependencyResolveDetails details ->
        if (details.requested.group == 'androidx.appcompat') {
            details.useVersion '1.1.0'
        }
    }
}

上記のように 1.1.0 とのリンクを明示することで、動作は可能です。

ダウングレードの注意

なおライブラリ側をダウングレードさせるのは危険なのでご注意ください。

appcompact では他にも ActionBarOverlayLayout.onNestedScroll() の引数が追加 されており（ 1.0.0 にない I/F が追加 ）、ライブラリ開発者がこの I/F で開発を行っていた場合に 1.0.0 と強制リンクを行うと、ビルドは成功し何となく動きます(※)

※インスタンス化する程度ではクラッシュしませんでした。

このとき考えられる弊害としては、
実際のリンクは 1.0.0 と行っているため、新しい I/F が呼ばれず古い onNestedScroll() が呼ばれることになり、ライブラリ開発者が想定していたロジックが呼ばれず... 気づきにくいバグ事象となります。

アップグレードする場合は、appcompact の変更点を確認してからするのが確実です。

参考

appcompat:1.1.0 について
activity:1.0.0 について
fragment:1.1.0 について

はじめに

Android Support LibraryからAndroid xへ移行手順を書いていきたいと思います。
手順は簡単ですし、Developerサイト見れば一発で分かりますが画像メインでいきます。

環境

OS:Windows 10
Android Studio：3.5(統合は3.2以上だそうです)

移行前

赤のアンダーライン引いてるところがSupport Libraryです。

手順

[Refactor] > [Migrate to AndroidX...]

[Migrate]
※変更前のものをZIP化して保存しておきたい場合は「Backup project as Zip file」にチェック（デフォルトチェック済み）

[Do Refactor]

移行後

移行後は以下のようにandroidxに置き換わっています。

参考文献

公式

出来ること

• Expoで展開したWebViewのlogなんかをChromeDevToolで見られる
• WebView生成後の確認

出来ないこと

• 実機での確認

手順

• AndroidStudioからAndroidエミュレーターの起動
• expo start でexpoの起動
• expo startで開かれたwebサイト上の Run on Android device/emulatorをクリックしてエミュレーターでApp起動
  • この時、PCに複数のエミュレーターや実機が刺さっていると怒られる
• chrome://inspect/#devices をchromeで開くと対象のWebViewが出ているので確認できる
  • 出てない場合はエミュレーターが開発者モードになってないのかも(build番号何回かTapするやつ

おまけ

• 下記みたいなの見つけて絶望したけど出来た https://expo.canny.io/feature-requests/p/support-running-debugger-against-webview-without-native-changes https://github.com/expo/expo/issues/485
• modules内のktファイルいじったり色々したけど無駄だった