Googleコンタクト から iCloud連絡先 へ完全移行する手順 - 連絡先 / コンタクトの使い方まとめ その4 【Android → iPhone】

iPhone上の 連絡先アプリ で Googleコンタクトのデータを同期(共有)している状態から、iPhone と iCloud連絡先 連携のみの状態に完全移行します。

今回は、「Android と iPhone のみで完全移行する」のと「Mac (パソコン) を利用して完全移行する」の2つの手順で考えてみます。

 

👥 Android と iPhone のみで完全移行する

スタートは、iPhone上の連絡先アプリ で Googleコンタクト のデータを同期 (共有) している状態からです。

iPhone 上の連絡先アプリで Googleコンタクト のデータを同期 (共有) している状態から、iPhone + iCloud 連絡先に完全移行します。

iCloud連絡先を有効化 します。

iCloud 連絡先を有効化 します。

iPhone連絡先アプリ から Googleコンタクトアカウントを無効化 します。

iPhone 連絡先アプリ からGoogle コンタクトアカウントを無効化します。

Android側で vCard 形式でエクスポートした vcfファイルをメールに添付して iPhone に送信します。

Android 側で vCard 形式でエクスポートする。 メールに添付して iPhone に送る。 iPhone 上で受信したメールの添付ファイルをタップしてインポートする。

iPhone上で受信したメールの添付ファイルをタップしてインポートします。

以下のようになり完全移行完了しました。

完全移行完了。

 

👥 Mac (パソコン) を利用して完全移行する

Mac上でやるとファイル移動の手間がかからず、複数のGoogleコンタクトアカウントを持っているときなどにも柔軟に操作できます。

GoogleコンタクトデータをAndroid、Mac、iPhone の3つで同期(共有)しているところから始めてみます。

連絡先データはすべてGoogleコンタクトに保存する。 メールの設定との関係もある。 デフォルトのアカウントの設定で新規保存先をGoogleアカウント側に向けておく必要がある。

iPhoneで Googleアカウントを無効化 します。

iPhone で Googleアカウントを無効化します。

Mac と iPhone で iCloudを有効化 します。

Mac と iPhone で iCloud を有効化します。

Mac上で、Googleコンタクト や 同期済みの連絡帳アプリ からエクスポートします。

Mac 上でGoogleコンタクトや連絡帳アプリからエクスポートする。 Mac 上でやるとファイル移動の手間がかからないので簡単です。

ブラウザからは、Googleコンタクトからエクスポートです。
Mac上で、Googleコンタクト や 同期済みの連絡帳アプリ からエクスポートします。

連絡先アプリでは、メニューから以下でエクスポートします。


[ファイル]

  ↓

[書き出す]

  ↓

[vCardを書き出す]

Mac上で、Googleコンタクト や 同期済みの連絡帳アプリ からエクスポートします。

続いて、パソコン上で エクスポートして不要になった Googleコンタクトアカウントを無効化します。

メニューから、


[連絡先]

  ↓

[環境設定]

  ↓

[アカウント]

  ↓

(Googleコンタクトアカウントを選択)

  ↓

[このアカウントを有効にする] をOFF

パソコン上で Google コンタクトを無効化します。

エクスポートしたvCardファイルを iCloud連絡先にインポートします。

先に、パソコン上で Google コンタクトを無効化する。 iCloud 側にインポートする。
メニューから以下でインポートです。


[ファイル]

  ↓

[読み込む]

  ↓

(vCardファイルを選択)

お疲れさまです。完全移行完了です。

Google と Apple のクラウドを利用した連絡先データ連携系統がくっきり2つに分かれました。

iPhone上では、Googleコンタクトを利用せずに連絡先データを使えるようになります。

完全移行完了。

iCloud 連絡先 にデータを完全移行することで、Googleコンタクトの設定は関係なしに、Appleデバイス間で連絡先データを共有できます。

クラウド側のデータを参照するアプリによって制限があるのがややこしくさせています。

Googleコンタクト から iCloud連絡先 へ完全移行する手順 - 連絡先 / コンタクトの使い方まとめ

まあ、サードパーティアプリでできるのだろうが、まずは、Google、Apple それぞれの意図意向を把握しておきます。

👉 連絡先をクラウド上に保存する - 連絡先 / コンタクトの使い方まとめ その1【Android / iPhone】 
👉 Google コンタクト データをAndroid と iPhone で共有する - 連絡先 / コンタクトの使い方まとめ その2【Android / iPhone】 
👉 連絡先アプリ 必ず把握しておくべき全設定画面別使い方メモ- 連絡先 / コンタクトの使い方まとめ その3【Android → iPhone】 
👉 iPhone連絡先アプリ だけが iCloud連絡先 のデータをエクスポートできない件 


Error: ComponentProcessingStep was unable to process 'AppApplication_HiltComponents.SingletonC' because 'DefaultActivityViewModelFactory' could not be resolved.

Releases dagger-2.34
Dagger2.34 にアップデートしたら全くビルドが通らず。

Error: ComponentProcessingStep was unable to process 'com.example.eg.AppApplication_HiltComponents.SingletonC' because 'dagger.hilt.android.internal.lifecycle.DefaultActivityViewModelFactory' could not be resolved.

なんすかねこれ。

 

androidx.hilt:hilt-lifecycle-viewmodel が不要

Hmm, the androidx.hilt:hilt-lifecycle-viewmodel artifacts were deprecated in the Dagger 2.34 release in favor of native Hilt API. The missing DefaultActivityViewModelFactory class is no longer in the Hilt codebase.

You should be able to fix this using the instructions in the 2.34 release notes to upgrade to the new HiltViewModel API.

androidx.hilt:hilt-lifecycle-viewmodel アーティファクトはDagger 2.34リリースで非推奨となり、ネイティブHilt APIに切り替わりました。

👉 ComponentProcessingStep was unable to process '*Application_HiltComponents.SingletonC' · Issue #3257 · google/dagger

New breaking changes
The alpha androidx extension @ViewModelInject is no longer supported. @ViewModelInject has been deprecated since androidx.hilt 1.0.0-alpha03 and was removed in androidx.hilt 1.0.0-beta01. Hilt now falls back to the base activity/fragment default ViewModelProviderFactory (3778ee2)

Migration steps:
Users of @ViewModelInject can migrate to @HiltViewModel which was added in Dagger 2.31.

1. Add @HiltViewModel annotation to the class
2. Replace the @ViewModelInject annotation on the constructor with @Inject.
3. Remove @Assisted from the SavedStateHandle constructor parameter, if it exists
4. Remove the old androidx.hilt:hilt-lifecycle-viewmodel dependency from your build.gradle file

👉 Release Dagger 2.34 · google/dagger 

私の場合は、上記の手順を確認して build.gradle を修正でビルド通るようになりました。削除漏れです。

androidx.hilt:hilt-lifecycle-viewmodel artifacts were deprecated in the Dagger 2.34 release in favor of native Hilt API.

build ファイルの削除漏れが影響を及ぼすことが結構多くなりました、最近。


【Playストア】今現在のアプリ更新時の審査日数を調べる方法

アプリ更新後のリリースされるタイミングをスクリプトで検知したりしていましたが。



👉 Play ストアから現在公開中のバージョンを取得する 
👉 macOS でスクリプトから通知を出す。 

この公開されるまでの時間が長くなったのは、コロナ禍の影響なのか、審査を細かく見るようになったからか、何なのか。


気になったので少し調べてみました。

アプリ名 アップロード日 ストア公開日 所要日数
YouTube 2/10 2/13 3
Amazonショッピング 2/2 2/10 8
Amazonプライムビデオ 2/8 2/10 2
ツイキャス 2/10 2/11 1
TouTubeStudio 2/3 2/10 7
Spotify 2/8 2/9 1
Googleカレンダー 2/1 2/9 8
Twitter 2/8 2/9 1
Google Keep 2/1 2/9 8
ABEMA 2/4 2/9 5
Googleフォト 2/9 2/9 0
メルカリ 2/4 2/9 5
インスタ 2/7 2/8 1
Facebook 2/12 2/13 1
Googleマップ 2/3 2/6 6
Googleドライブ 2/4 2/8 4
Google 2/4 2/7 3
Tver 2/3 2/4 1
Google Fit 1/31 2/4 4
Chrome 2/1 2/4 3
SpeedTest 1/19 2/3 15
Gboard 2/1 2/2 1
ニコ生 1/26 1/31 5

 

調べ方

Google Play ストアアプリで、右上アカウントから、


[アプリとデバイスの管理]

  ↓

[最近の更新を見る]

  ↓

[最近更新したアプリ]

たとえば、アプリ「ツイキャス」で見てみると、

【Playストア】今現在のアプリ更新時の審査日数を調べる方法

今現在が、2/15 なので、審査が終わって、ストアに公開されて、端末が検知して、更新したのが「4日前」の「2/11」。

タップして詳細画面へ。

【Playストア】今現在のアプリ更新時の審査日数を調べる方法

開発者は分かってると思うが、「最終更新」は更新内容をアップロードしたタイミング。

この場合は「2/10」。

よって、

アップロード日 : 2/10
ストア公開日 : 2/11

となり、この2つの差の所要日数の「1日間」が審査日数に近いはず。

Playストアのアプリのキャッシュの影響などもあるのだが、頻繁に手動でアプリ更新をしていれば精度は上がる。

まあ、機種、OSバージョン別パッケージなどの話はあるが、全体的な雰囲気は分かる。

 

まとめ

上の表を眺めていると、アプリのカテゴリーで審査のスピードが違うような、なんとなくだが。

SNS、動画、音楽、ライブ配信
→ 3日以内

それ以外は大体1週間前後。


しかし、私のアプリはなぜそんなに時間がかかったのか。

ゴミアプリだからですか、すいません。