cocoa-mhlw / cocoa Goto Github PK

PR #19 を現運用方針に合わせるために建てた Issue です。
詳細は #19 をご覧下さい。

Describe the bug
https://www.mhlw.go.jp/stf/newpage_16841.html

本来であれば、本アプリはGoogle社が提供する接触通知機能と連動し、陽性者が通知サーバーに登録した接触に関する情報を１日に１回程度各端末にダウンロードし、各端末内の記録と照合・通知を行う仕組みとなっています。Android端末13台/13ケースを用いて36時間後の状態を確認した限定的な検証の結果、本アプリがバックグラウンドから強制終了されてしまうことにより当該処理が実行されないケース、あるいはバックグラウンドで起動している状態であっても当該処理を定期的に実行していないケースが７ケース見つかりました。

Expected behavior
設定した間隔ごとにバックグラウンドタスクが実行される。

Smartphone (please complete the following information):

• Device: Essential PH-1
• OS: Android 10

考えられる原因

バックグラウンドタスクの処理実体Covid19Radar.Services.ExposureNotificationHandler内でDependencyService.Resolveを使って依存性の注入（Dependency Injection）をしていることが原因と考えられる。

private ILoggerService LoggerService => DependencyService.Resolve<ILoggerService>();
private IHttpDataService HttpDataService => DependencyService.Resolve<IHttpDataService>();
private IExposureNotificationService ExposureNotificationService => DependencyService.Resolve<IExposureNotificationService>();

これらの依存はCovid19Radar.Appで設定されている。Covid19Radar.Appの実行はCovid19Radar.Droid.MainActivityのonCreateでLoadApplicationするタイミング（アプリの起動と同義）となる。

ユーザーがCOCOAアプリを起動した後、Covid19Radar.Appが初期化されアプリのプロセスが残っている状態で前述のDependencyService.Resolveが行われた場合、バックグラウンド処理は問題なく実行される。

しかし、メモリ不足などの理由でAndroidのシステムがアプリのプロセスを終了した場合、次にユーザーがアプリ（MainActivity）を起動するまでDependencyService.Resolveは正しく実行されない。

Covid19Radar.Appが初期化されていない状態でDependencyService.Resolveで取得したLoggerService, HttpDataService, ExposureNotificationServiceを使用した場合、例外（System.Reflection.TargetInvocationException）が発生することが確認されている。
結果としてバックグラウンド処理は失敗し、このケースではLoggerServiceも正しく機能しないので、ログも取得できていないものと思われる。

また、バックグラウンドはWorkManager(JobScheduler)によって定期実行が設定され、端末を再起動した場合もWorkManagerによる定期実行は継続する。
端末の再起動後、ユーザーがアプリを起動していない状態で定期実行が開始された場合も、Covid19Radar.Appが行われていない状態でバックグラウンドタスクが実行されることになる。

考えられる対策

バックグラウンドタスクの実行時、Covid19Radar.Services.ExposureNotificationHandler内のLoggerService, HttpDataService, ExposureNotificationServiceの3つのインスタンスが利用可能になるようにプログラムを変更する。

考えられる方法としては、DependencyService.Resolveを行わず前述した3つのインスタンスを生成するようにする。
または、Covid19Radar.Droid.MainActivityを起動する以外の方法でDependencyService.Resolveが正しく実行されるようにプログラムを変更する。

解消までの課題

DependencyService.Resolveを使わずに依存の解決を行うことは容易ではない。前述の3つのインスタンスは、さらに複数のクラスに依存しており、それらすべてを適切にインスタンス化する必要がある。

また、依存関係は最終的には各プラットフォーム（Android, iOS）固有のクラスに到達する（AndroidではCovid19Radar.Droid.MainActivity.AndroidInitializer）。

プラットフォーム固有クラスの依存は、各プラットフォームのプロジェクト（「Covid19Rader.Android」および「Covid19Rader.iOS」）の中で設定され、「Covid19Radar」のプロジェクトからは直接参照していない。
「Covid19Radar」プロジェクト内にあるCovid19Radar.Services.ExposureNotificationHandlerからプラットフォーム固有クラスは参照できない。

Xamarinでどのように解決するのが正しいか。UnityのようなDIコンテナを導入することで解決できるものか。調査と検討が必要となる。

不具合の内容 / Describe the bug

• ログのローテート処理 (LogFileService クラスの Rotate メソッド)が正しく呼び出されないおそれがあります

再現手順 / Steps to reproduce

ストアを利用しないと検証できない事象なのでコード上の確認のみですが、以下のような手順での検証が必要だと考えられます。

1. PlayStore にクローズドベータ版で問題ないので COCOA をアップロード
2. ストア公開版アプリをインストールして初期設定後 1. のベータ版に更新
3. 更新後、アプリアイコンから起動せず、かつ端末を再起動せずに 24時間以上経過後、ログがローテートされているか確認

期待される挙動 / Expected behavior

• 24時間以内にはログがローテートされること
• 特に、次バージョンで TEK の定期ダウンロード処理が正常化した場合に、単一のログファイルに大量のログが保存され続けることがないようにすること

スクリーンショット / Screenshots

動作環境 / Environments

• デバイス：Android ならどれでも（例：Pixel 5、iPhone 6 等）
• OS：Android（例：Android、iOS）
• バージョン：1.2.1 以降 (例：1.2.2)

その他 / Additional context

v1.2.2 のコードでは、私が理解している動作としては以下のようになっています。

• Android 版では LogPeriodicDeleteServiceAndroid.cs にある LogPeriodicDeleteReceiver を 2箇所から呼び出しています
  • AlarmManager の PendingIntent

    cocoa/Covid19Radar/Covid19Radar.Android/Services/Logs/LogPeriodicDeleteServiceAndroid.cs

    Line 36 in b823e87

    var intent = new Intent(context, typeof(LogPeriodicDeleteReceiver));

  • AndroidManifest.xml への android.intent.action.BOOT_COMPLETED の登録

    cocoa/Covid19Radar/Covid19Radar.Android/Services/Logs/LogPeriodicDeleteServiceAndroid.cs

    Line 50 in b823e87

    [IntentFilter(new[] { Intent.ActionBootCompleted })]

• また、AlarmManager への登録処理は、以下の 2箇所を通った場合に行われます
  • App.xaml.cs の OnStart から LogPeriodicDeleteServiceAndroid クラスの Init メソッド → SetNextSchedule メソッドの呼び出し

    cocoa/Covid19Radar/Covid19Radar/App.xaml.cs

    Line 149 in b823e87

    logPeriodicDeleteService.Init();

  • LogPeriodicDeleteReceiver の OnReceive から SetNextSchedule メソッドの呼び出し(ローテート処理が1度呼び出された場合には次回を設定している)

    cocoa/Covid19Radar/Covid19Radar.Android/Services/Logs/LogPeriodicDeleteServiceAndroid.cs

    Line 71 in b823e87

    var nextScheduledTime = LogPeriodicDeleteServiceAndroid.SetNextSchedule();

• その他、LogFileService の Rotate メソッドを App.xaml.cs と SendLogConfirmationPageViewModel から呼び出し(今回の現象にあまり関係がないので省略)

言い換えると、以下の場合には SetNextSchedule が呼ばれるので正しいように見えるのですが

• アプリ通常起動時 (App.xaml.cs)
• 端末再起動時 (BOOT_COMPLETED broadcast)

アプリをアップデートした場合には、AlarmManager の登録内容はいったんクリアされるはずなので、上記の2つのいずれかを実行するまで、AlarmManager による定期起動が行われないのではないでしょうか。

一見条件が厳しいようにも見えますが、アプリを自動アップデートする設定にしていて COCOA をふだん起動しないユーザが当てはまるので、確認・対応しておいた方が望ましいと考えています(とはいえログファイルのサイズが巨大化する可能性があるだけなので、動かないよりはマシですが)

解決方法としては以下のような方法が考えられるかと思います

• AlarmManager をやめて WorkManager に置き換え (アプリアップデート後も再設定の処理は自動的に行われる)
• android.intent.action.MY_PACKAGE_REPLACED などの broadcast を受信して AlarmManager を初期化する(念のためOSバージョンなどの制限がないか調査かテストが必要)
• ログ出力時にもローテートが必要かどうかのチェックを行うように修正(どうしても他の方法が取れない場合)

その機能リクエストは何らかの問題に関連しますか / Is your feature request related to a problem?

機能リクエスト以前に、運用基礎データをどの程度集計して開示できるかの検討が必要かと考えます。

以下のような目的を想定しています

• 機能リクエストの検討の際に参考とする
• 機能追加や不具合改修時にデータにどのように反映されるかを事前に検討する
• 運用上集められないデータがあるならば、そのボトルネックがなんなのかを明らかにしておく

解決策についてお書きください / Describe the solution you'd like

個人を特定するようなデータは集めない方針なのは前提として、
厚労省として集計しているデータ全てを出すことができない事情はあるかもしれませんが、
現状は公表されている情報がなさすぎると感じています。

• どのようなデータを集めているかの項目の開示と整理
• どのようなデータは集めないことに方針決定されているかの開示
• 開示しても問題ないものはデータそのものの開示

を検討いただければと思います。具体的に必要と考えるデータについては私がどうこういうよりも
issue 内で議論してもよさそうです。

あなたが考える代替案についてご説明ください / Describe alternatives you've considered

運用そのものを透明化することはこのプロジェクトでは目的とされていないのかもしれないですので、
クローズドで運用するという決定であればそれはそれで問題はないと思ってはいます。

ですが、オープンプロセスという試みとのことでしたのでできれば前向きな議論がなされることを期待したいです

その他 / Additional context

また、そもそも github はソースレベル・開発レベルのみの話に限定したくて、
運用については範囲外であるということであれば close いただいてもいいのですが、
github のスコープを明示するような対応を別途行っていただくとよいかなと感じています

不具合の内容 / Describe the bug

iOS版のCOCOAは現在、日本語、英語、**語のリソースを持っています。対応言語以外のリソース（デフォルトリソース、Base.lproj以下）として日本語が書かれた画像が指定されています。

https://github.com/cocoa-mhlw/cocoa/blob/master/Covid19Radar/Covid19Radar.iOS/Resources/Base.lproj/HelpPage21%402x.png

一方、Androidでは英語リソースがデフォルトリソースとして指定されています。

https://github.com/cocoa-mhlw/cocoa/blob/master/Covid19Radar/Covid19Radar.Android/Resources/drawable-xxhdpi/HelpPage21.png

文字列リソースについては英語がデフォルトという認識しており、iOS版の画像のデフォルトリソースを英語に変更することを提案します。

再現手順 / Steps to reproduce

1. システム設定から言語を「日本語」「英語」「**語」以外（たとえばドイツ語）に設定する
2. COCOAを起動する（すでに起動している場合は一度タスクを削除する）

期待される挙動 / Expected behavior

英語の画像が表示される

動作環境 / Environments

• デバイス：すべてのiOS端末
• OS：iOS
• バージョン：1.2.2で確認

Internal IDs:

• BUG 1698

今の状態では null 安全ではありません。不具合を減らす為には null 許容型/非許容型を有効にすべきでしょう。プロジェクト全体の設定を変えるのが大変であれば、#nullable ディレクティブを使う事もできます。

Internal IDs:

• NFR 2948

Describe the bug
Xamarin.Androidを11.2.0.0にアップデートすると、エラー「MSB3375」が発生してXamarin.ExposureNotificationのビルドに失敗する。

/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Legacy.targets(5,5): Error MSB3375: The file "obj/Debug/monoandroid10.0/__AndroidLibraryProjects__.zip" does not exist. (MSB3375) (Xamarin.ExposureNotification)

To Reproduce
再現試験はお薦めしない。
一度この現象が発生すると、不具合を解消したXamarin.Androidへの更新を行うか、後述するワークアラウンドを実施するまで現象は改善しない。

Steps to reproduce the behavior:

1. Xamarin.Androidを11.2.0.0にアップデートする（更新通知から。または最新版のVisual Studio for Macをインストールする）
2. COCOAのソリューションを開いてビルドを実行
3. See error

Expected behavior
正常にビルドが完了する

Desktop (please complete the following information):

• OS: macOS 11.2.1 - 11.2.3
• Visual Studio for Mac 8.9
• Xamarin.Android 11.2.0.0 xamarin-android/d16-9/f908d16

Additional context
本現象はVisual Studioの公式フォーラムではすでに報告されている。

https://developercommunity2.visualstudio.com/t/Error-MSB3375-compiling-XamarinAndroid-/1315848?viewtype=solutions

fix済みのバージョンが配信とのリプライはあるものの、最新版のVisual Studio for Macでも事象の発生を確認している。Windowsを対象にした配信でfor Macはまだ修正されていない可能性がある。

Workaround
/Library/Frameworks/Xamarin.Android.framework/Versions/11.2.0.0/lib/xamarin.android/xbuild/Xamarin/Android/Xamarin.Android.Legacy.targetsの内容を変更する（要管理者権限）。

-     <Touch Files="$(IntermediateOutputPath)__AndroidLibraryProjects__.zip" />
+     <Touch Files="$(IntermediateOutputPath)__AndroidLibraryProjects__.zip" AlwaysCreate="true" />

詳細は次のコミットを参照のこと。

https://github.com/xamarin/xamarin-android/pull/5477/files#diff-47d20207182aad2c752c0fa397c77bd67457c3cda762b716be47e8d45c1ccda5L467-R467

アップデートは慎重に。

1月4日の突如として COCOA の継続日数が初期化されました。

初期化された後、再び同意をして使用を継続しているのですが、ログを見ていくと、初期化される前に常に
"existsUserData: False" な状態になっています。

"2020/12/26 00:02:18","Info","existsUserData: False","Get","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/UserDataService.cs","70","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"

この状態が、1/4 まで続きます。

"2021/01/04 23:39:48","Info","Start","Get","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/UserDataService.cs","67","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:48","Info","existsUserData: False","Get","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/UserDataService.cs","70","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:48","Info","End","Get","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/UserDataService.cs","77","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:48","Info","No user data exists","OnInitialized","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/App.xaml.cs","80","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:48","Info","Transition to TutorialPage1","OnInitialized","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/App.xaml.cs","81","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:48","Info","End","OnInitialized","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/App.xaml.cs","99","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:49","Info","Start","Init","/Users/runner/work/1/s/Covid19Radar/Covid19Radar.iOS/Services/Logs/LogPeriodicDeleteServiceIos.cs","40","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:49","Info","Start","ScheduleAppRefresh","/Users/runner/work/1/s/Covid19Radar/Covid19Radar.iOS/Services/Logs/LogPeriodicDeleteServiceIos.cs","92","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:49","Info","request.EarliestBeginDate: 2021-01-05 14:39:49 +0000","ScheduleAppRefresh","/Users/runner/work/1/s/Covid19Radar/Covid19Radar.iOS/Services/Logs/LogPeriodicDeleteServiceIos.cs","98","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:49","Info","End","ScheduleAppRefresh","/Users/runner/work/1/s/Covid19Radar/Covid19Radar.iOS/Services/Logs/LogPeriodicDeleteServiceIos.cs","107","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:49","Info","End","Init","/Users/runner/work/1/s/Covid19Radar/Covid19Radar.iOS/Services/Logs/LogPeriodicDeleteServiceIos.cs","49","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:49","Info","Start","Rotate","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/Logs/LogFileService.cs","128","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:49","Info","End","Rotate","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/Logs/LogFileService.cs","147","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:52","Info","Start","Get","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/UserDataService.cs","67","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:52","Info","existsUserData: False","Get","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/UserDataService.cs","70","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:52","Info","End","Get","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/UserDataService.cs","77","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:57","Info","Start","OnClickAgree","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/ViewModels/Tutorial/TutorialPage3ViewModel.cs","35","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:57","Info","No user data exists","OnClickAgree","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/ViewModels/Tutorial/TutorialPage3ViewModel.cs","40","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:57","Info","Start","RegisterUserAsync","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/UserDataService.cs","44","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:57","Info","Start","PostRegisterUserAsync","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/HttpDataService.cs","62","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:57","Info","End","PostRegisterUserAsync","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/HttpDataService.cs","81","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:57","Info","userData is not null","RegisterUserAsync","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/UserDataService.cs","52","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:57","Info","Start","SetAsync","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/UserDataService.cs","83","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:57","Info","currentdata don't equals newdata","SetAsync","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/UserDataService.cs","93","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:57","Info","Start","Get","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/UserDataService.cs","67","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:57","Info","existsUserData: True","Get","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/UserDataService.cs","70","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:57","Info","End","Get","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/UserDataService.cs","73","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:57","Info","End","SetAsync","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/UserDataService.cs","100","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:57","Info","End","RegisterUserAsync","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/UserDataService.cs","61","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:57","Info","userData is not null","OnClickAgree","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/ViewModels/Tutorial/TutorialPage3ViewModel.cs","50","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:57","Info","Start","SetAsync","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/UserDataService.cs","83","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:57","Info","currentdata don't equals newdata","SetAsync","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/UserDataService.cs","93","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:57","Info","Start","Get","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/UserDataService.cs","67","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:57","Info","existsUserData: True","Get","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/UserDataService.cs","70","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:57","Info","End","Get","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/UserDataService.cs","73","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:57","Info","End","SetAsync","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/UserDataService.cs","100","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:57","Info","IsOptined set to True","OnClickAgree","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/ViewModels/Tutorial/TutorialPage3ViewModel.cs","59","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:57","Info","Start","SaveLastUpdateDateAsync","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/TermsUpdateService.cs","106","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:57","Info","End","SaveLastUpdateDateAsync","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/TermsUpdateService.cs","111","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:57","Info","Start","Get","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/UserDataService.cs","67","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:57","Info","existsUserData: True","Get","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/UserDataService.cs","70","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:57","Info","End","Get","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/UserDataService.cs","73","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:39:58","Info","End","OnClickAgree","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/ViewModels/Tutorial/TutorialPage3ViewModel.cs","63","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:40:49","Info","Start","Rotate","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/Logs/LogFileService.cs","128","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:40:49","Info","End","Rotate","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/Logs/LogFileService.cs","147","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:40:50","Info","Start","OnClickAgree","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/ViewModels/Tutorial/PrivacyPolicyPageViewModel.cs","41","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:40:50","Info","Start","SetAsync","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/UserDataService.cs","83","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"
"2021/01/04 23:40:50","Info","currentdata don't equals newdata","SetAsync","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/UserDataService.cs","93","iOS","14.2","iPhone11,8","Physical","1.2.1","1607653212"

同意をすると、再び "existsUserData: True" な状態になります。

この動作は想定されているものでしょうか？

Describe the bug

ユーザー補助オプション「アニメーションの削除」が反映されず、一部の画面遷移がアニメーションを伴って行われる。

To Reproduce

1. 「設定」アプリの「ユーザー補助」→「アニメーションの削除」を有効にする
2. COCOAを起動する
3. ホーム画面の各ボタン、あるいは右上「使い方」およびそれ以下の各項目をタップする
4. アニメーションを伴って画面が遷移する

Expected behavior

「アニメーションの削除」が有効の場合はアニメーションを伴わずに画面遷移が行われる。

Smartphone (please complete the following information):

• Device: SH-M08
• OS: Android 10
• COCOA Version: 1.2.2

Internal IDs:

• Bug 2949

社用スマホとプライベートのスマホ両方に
接触確認アプリをインストールして使っていた場合、
処理番号はどの様に入力するのか。

システム上、未対応？
運用上どの様にする？

HER-SYSからは"1人1つの処理番号"が発行されるはず。
その処理番号は"1度きりしか利用出来ない"はずである。

企業での社用スマホへの導入も増えつつあり
今後はこの様な陽性者の方も増えると予想される。

アプリのサポートへ質問中。

iPhone 6s 以下のモデルにはiOS 13へのアップデートが不可能ため、接触アプリにはiOS12ではサポートできないため、DLできません。iOS12がサポートできればありがたいですね。

ご検討のほど、よろしくお願いいたします。

Internal IDs:

• Product Backlog Item 1678

Describe the bug

標準メールアプリのアカウントが１つも設定されてないと、代わりにGmailのメール編集画面が開くが、その際にお問い合わせのTo欄が空になっていて送信できない。
標準メールアプリでは問題なし。

To Reproduce

1. デフォルトのメールアプリを、設定されたメールアカウントがない状態にする
2. Gmailをインストール・設定済みにしておく
3. お問い合わせボタンを押す
4. Gmailの編集画面が立ち上がるが、To欄が空になっている

Expected behavior

To欄にお問い合わせメールアドレスが入力されている

Smartphone (please complete the following information):

• Device: iPhone 12
• OS: iOS 14.3
• Browser Chrome
• Version 1.2.1

#16 のバグ報告をしようとして発見しました。
下記のEmail.ComposeAsync()のバグ？を踏んでいるようです。
xamarin/Essentials#1401 (comment)

Internal IDs:

• BUG 1835

iOS版のコードを追いかけていて気が付いたのですが、zipファイルのダウンロード完了後に処理が中断した場合、この時のzipファイルに含まれる診断キーとの接触チェックが行われずに漏れてしまうように思えます。具体的には、次の行以降です。

この行のメソッドでは、各zipファイルのCreatedの値を、最後にダウンロードしたzipファイルのCreatedであるlastTekTimestamp[region]と比較し、ダウンロードするかどうかを決めています。

lastTekTimestamp[region]はダウンロード毎に更新されます。すべてのzipファイルがダウンロードされるとlastTekTimestampがuserData.LastProcessTekTimestampに反映され、直後にuserDataの保存処理が呼ばれます。

接触チェックはダウンロード後に行われるため、ダウンロードしかしていなくてもuserData.LastProcessTekTimestampが更新され、次回のダウンロードに参照されます。

チェックの対象になるのは直前のダウンロードされたzipファイルのみなので、未チェックのファイルを見つけてこれに加えるような仕組みがないのであれば、冒頭で挙げたところで中断した場合は、その分が対象になりません。

C#のコーディング経験がないため勘違いもあるかもしれませんが、影響が大きいと思いましたので検証していただけると幸いです。

Internal IDs:

• Bug 1518

Is your feature request related to a problem? Please describe.

CONTRIBUTING.md の中で、* waiting ラベルがついた Issue は・・・
とあるが、waiting-for-confirmation ラベルにしたので修正。

リポジトリのルート直下にライセンスを明記したファイルが 2 つあります（LICENSE.txt と LICENSE.md）。どちらも同一の内容ですから，一方を削除した方がよろしいかと思われます。なお，「About」の欄にある「LICENSE」のリンクは，LICENSE.md を参照しているようです。

不具合の内容 / Describe the bug

陽性情報の登録画面で、「陽性情報登録」ボタンを押した後に表示される確認ダイアログのPositive Buttonのラベルが「同意する」になっている。

再現手順 / Steps to reproduce

1. '陽性情報の登録' に行き、必要事項を入力
2. '登録する' のボタンを押すと、
3. 表示される「陽性情報を登録しますか？」のダイアログのPositive Buttonのラベルが「同意する」になっている

期待される挙動 / Expected behavior

ユーザーの目的は陽性情報を登録することで、直前のボタンも「登録する」表記なのでPositive Buttonのラベルは「登録する」または「登録」がより適切と考えます。

スクリーンショット / Screenshots

動作環境 / Environments

• デバイス：Android、iPhone 6
• OS：Android、iOS
• バージョン：すべてのバージョン
• システム言語：日本語

Internal Tracking ID: BUG 1784

1. latest iOS version.
2. I tried to install the App in Switzerland and I got this error, see image below.
3. The error says "Network Connection Error."
4. My phone is fully connected.
   

Describe the solution you'd like
アプリのストア公開前にリリースブランチで次回リリース予定の内容を開示して整理してみてはどうでしょうか

Additional context
前回 v1.2.2 のリリースではAndroid版での不具合が残ったままリリースすることになってしまったのですが、そういった事態をなくす(減らしていく)ための提案です。

具体的にリリースブランチをどう運用するかにはいくつか方法がありそうです。
これまでは master でストアの最新版ソースを開示する方針だったと思いますので、それを踏襲すると以下のような運用(案)が考えられると思います

• たとえば rc1.2.3 のようなブランチで次回リリースの内容を整理
• 実際にストアにリリースした際に rc1.2.3 ブランチを master にマージ
• master へのマージコミットに v1.2.3 タグをつけて、rc1.2.3 ブランチを削除

以下のページでは develop ブランチからの例ですが参考になるかもしれません
cf. https://dev.classmethod.jp/articles/git-flow-release/

既に厚生労働省にメール済みですが、記録として issue にも上げておきます。

※悪意利用の可能性があるので、詳細は伏せます。

不具合の内容 / Describe the bug

動作未検証なのですが、AppCenter の使用コードが一部残っており、動作ログを送信していないか確認が必要ではないでしょうか

再現手順 / Steps to reproduce

再現確認はしていません。

ソース上、以下の点が気になっています

• NuGet の Prism.Plugin.Logging.AppCenter パッケージへの依存がある

  cocoa/Covid19Radar/Covid19Radar/Covid19Radar.csproj

  Line 111 in 61455db

  <PackageReference Include="Prism.Plugin.Logging.AppCenter" Version="7.2.0.1114" />

• ソース上も using Prism.Logging の記述箇所がある

  cocoa/Covid19Radar/Covid19Radar/Services/FFImageLoadingLogger.cs

  Line 2 in 20f3e8c

  using Prism.Logging;

  cocoa/Covid19Radar/Covid19Radar/Services/DebugLogger.cs

  Line 2 in 20f3e8c

  using Prism.Logging;

• FFImageLoading 自体は各 xaml から使用している
• FFImageLoadingLogger クラスは参照箇所はないかも
• DebugLogger クラスは Android では使用していないが iOS では使用している

  cocoa/Covid19Radar/Covid19Radar.iOS/AppDelegate.cs

  Line 34 in 20f3e8c

  Logger = new Covid19Radar.Services.DebugLogger()

単に削除漏れで無駄な依存関係があるだけかもしれないですが、念のため DebugLogger の出力が AppCenter に送られていないか検証した方がよさそうと考えています

期待される挙動 / Expected behavior

AppCenter へは動作ログなどを一切送信しないこと

動作環境 / Environments

• デバイス： 実機では未検証（例：Pixel 5、iPhone 6 等）
• OS： iOS（例：Android、iOS）
• バージョン： 1.2.2 以前全て (例：1.2.2)

その他 / Additional context

プライバシーポリシーとの矛盾の可能性があるため単に削除というよりは要検証という記載にしてみました。

とはいえ Prism.Logging.AppCenter の挙動や使い方を調べていませんので、コード上でのチェックでも問題ないということかもしれないです(その場合は削除すればそれで問題ないかとは思います)

また、手元では Prism.Logging.AppCenter への依存を削除してもビルドなどには問題なさそうでした(Android のみしか試していないですが)

接触管理アプリ COCOPA をインストールした後、同意を行ったときに、サーバーから UserUuid というものが渡されるようです。

コードを見るとこの UserUuid を陽性者登録するときにも使っているのですが、ユーザーを特定できる可能性があるコードですので、取り除いたほうがよいのではないでしょうか。

• UserDataModel
  • https://github.com/cocoa-mhlw/cocoa/blob/master/Covid19Radar/Covid19Radar/Model/UserDataModel.cs

    public class UserDataModel : IEquatable<UserDataModel>
    {

        /// <summary>
        /// User UUID / take care misunderstand Becon ID
        /// </summary>
        /// <value>User UUID</value>
        public string UserUuid { get; set; } // ※

        /// <summary>
        /// Secret key
        /// </summary>
        /// <value>Secret Key</value>
        public string Secret { get; set; }

        /// <summary>
        /// Jump Consistent Seed
        /// </summary>
        /// <value>Jump Consistent Seed</value>
        public ulong JumpConsistentSeed { get; set; }

        /// <summary>
        /// StartDate
        /// </summary>
        public DateTime StartDateTime { get; set; }

参照先

• 同意するときの呼び出し PostRegisterUserAsync
  • PostRegisterUserAsync
    • https://github.com/cocoa-mhlw/cocoa/blob/master/Covid19Radar/Covid19Radar/Services/HttpDataService.cs#L44
• 陽性者登録するときの呼び出し UploadSelfExposureKeysToServerAsync
  • UploadSelfExposureKeysToServerAsync
    • https://github.com/cocoa-mhlw/cocoa/blob/master/Covid19Radar/Covid19Radar/Services/ExposureNotificationHandler.cs#L223
  • CreateSubmissionAsync
    • https://github.com/cocoa-mhlw/cocoa/blob/master/Covid19Radar/Covid19Radar/Services/ExposureNotificationHandler.cs#L263
  • DiagnosisSubmissionParameter
    • https://github.com/cocoa-mhlw/cocoa/blob/master/Covid19Radar/Covid19Radar/Services/ExposureNotificationHandler.cs#L288

ご検討をお願いします。

その機能リクエストは何らかの問題に関連しますか / Is your feature request related to a problem?

Covid19Radar.Android下にあるResources/Resource.designer.csは、自動生成のファイル（Android ProjectのRに相当）なのでGitの管理から除外するのが適切と考えます。

現在はResource.designer.csがGitの管理下にあり、ソリューション（プロジェクト）を読み込むとResource.designer.csが読み込まれて、場合によっては更新されます（diffに載る）。そのままコミットするとResource.designer.csが更新された記録が積み上がっていきます。しかし、自動生成ファイルであるResource.designer.csには、バージョン管理システムで管理して、変更の差分を見る必然性は乏しいと考えます（このあたり、Xamarinをよく知る人の意見を聞きたいです）

Resource.designer.csが変更されている例
3e765cf#diff-19ac7f3b6ba8be87d398701aa40f7206e5cded2a5a772edf1da1fa4cd70c2257

解決策についてお書きください / Describe the solution you'd like

Resource.designer.csを.gitignoreファイルへ追加し、さらにCovid19Radar.Android/Resources/Resource.designer.csを削除したコミットをする。

あなたが考える代替案についてご説明ください / Describe alternatives you've considered

Pull RequestにResource.designer.csを含めないことを、PRレビュー前の必須事項とする（コントリビューターの手間を考えると、素直に.gitignoreに追加した方法が良いと思います）。

その他 / Additional context

参考記事

Xamarin 開発の GitIgnore ファイルを見直してみた - Xamarin 日本語情報
https://blog.ytabuchi.dev/entry/2017/11/15/123000

その機能リクエストは何らかの問題に関連しますか / Is your feature request related to a problem?

Xamarin EN v2 の対応のチェックのため。

解決策についてお書きください / Describe the solution you'd like

Xamarin EN v2 をコードベースをマージして、実機で試験をする。

あなたが考える代替案についてご説明ください / Describe alternatives you've considered

XamarinComponents/XPlat/ExposureNotification/source/Xamarin.ExposureNotification at dev/api-v2 · xamarin/XamarinComponents

この dev/api-v2 ブランチを cocoa v1.2.2 にマージしてあります。

Internal IDs:

• Feature 1664

Describe the bug
現状のソースではサービスロケータ/DIコンテナとして Xamarin.Forms の DependencyService と Prism.Ioc を混在して使用しています。

ですが、#25, #30 で議論されたように、Android の Service, Receiver が起動された場合 App.xaml.cs が初期化されないため
DependencyService が正しく動作しません。

また、DI コンテナを混在して使用する必然性はなく、Prism でも Prism7 以降では DependencyService との互換機能は削除すると記載があり古い機能という位置づけです(Prism has dropped all support for working with the DependencyService as of Prism 7.0.)
https://prismlibrary.com/docs/dependency-injection/platform-specific-services.html

Additional context
#22 では Prism 8.0 への更新を含んでいますので、その準備のためにも必要になる対応ではないかと想定しています。

Internal IDs:

• NFR 2586

ログ出力時に以下のコードが呼び出され、毎回ログファイルを開いています。

参考

• ログの書き込みを行うサービス：
  • https://github.com/Takym/Covid19Radar/blob/d460d2fbc14f5601728175f2bb769e7a53b86437/Covid19Radar/Covid19Radar/Services/Logs/LogWriter.cs
• ログの読み書きを行うサービス：
  • https://github.com/Takym/Covid19Radar/blob/db01a83ec186ca6af1eb49eb514c64dcceca5145/Covid19Radar/Covid19Radar/Services/Logs/LogReaderWriter.cs

Internal Tracking ID: NFR 2450

元となっている Covid19Radar の頃からいわれていることですが、不要なファイルが紛れ込みアプリケーションのサイズが肥大化しています。

機能的には放って置いても邪魔にならないので優先度は低いかも知れませんが、素人目に見てアプリの評価を下げたりインストールを避ける一因にはなっているようです。

過去の関連する Issue / PR

主にフォントリソースの重複登録などが原因の様です。
個々の Issue / PR が COCOA に反映されているかは確認していません。
また、これ以外の肥大化理由もあるかも知れません。

1. Covid-19Radar/Covid19Radar#588

2. Covid-19Radar/Covid19Radar#552

3. Covid-19Radar/Covid19Radar#560

4. Covid-19Radar/Covid19Radar#607

5. openCACAO/cocoa-issues#11

現時点（2021/01/10）で、接触者通知が発生しない現象が iPhone で見つかっています。

        // this will be called when a potential exposure has been detected
        public async Task ExposureDetectedAsync(ExposureDetectionSummary summary, Func<Task<IEnumerable<ExposureInfo>>> getExposureInfo)
        {
            loggerService.StartMethod();

            UserExposureSummary userExposureSummary = new UserExposureSummary(summary.DaysSinceLastExposure, summary.MatchedKeyCount, summary.HighestRiskScore, summary.AttenuationDurations, summary.SummationRiskScore);
            userData.ExposureSummary = userExposureSummary;

            loggerService.Info($"ExposureSummary.MatchedKeyCount: {userExposureSummary.MatchedKeyCount}");
            loggerService.Info($"ExposureSummary.DaysSinceLastExposure: {userExposureSummary.DaysSinceLastExposure}");
            loggerService.Info($"ExposureSummary.HighestRiskScore: {userExposureSummary.HighestRiskScore}");
            loggerService.Info($"ExposureSummary.AttenuationDurations: {string.Join(",", userExposureSummary.AttenuationDurations)}");
            loggerService.Info($"ExposureSummary.SummationRiskScore: {userExposureSummary.SummationRiskScore}");

            var config = await GetConfigurationAsync();

            if (userData.ExposureSummary.HighestRiskScore >= config.MinimumRiskScore)
            {
                var exposureInfo = await getExposureInfo();
                loggerService.Info($"ExposureInfo: {exposureInfo.Count()}");

この部分の userData.ExposureSummary.HighestRiskScore が 0 のため通知が発生していません。
OSでの接触カウントは1以上であるにも関わらず、HighestRiskScore が 0 となっています。
現象は、OS の ログ出力（loggerService.Info）で確認できています。

アプリの問題なのか、OS の問題なのかはわかりませんが、このままでは折角接触者通知のデータを受け取ったとしてもユーザーに通知がなされないため、見過ごしが起こり、アプリの目的が達成できないと思われます。
早急な調査をよろしくお願いします。

現象としては、ドイツの ENv2 の 問題も同じかもしれません。

Why is there no "MatchCount" in the EN-Log with v2 of ENF? ・ Issue #1731 ・ corona-warn-app/cwa-app-ios

参考先

detectExposuresWithConfiguration:diagnosisKeyURLs:completionHandler: | Apple Developer Documentation

maximumRiskScoreFullRange | Apple Developer Documentation https://developer.apple.com/documentation/exposurenotification/enexposuredetectionsummary/3601130-maximumriskscorefullrange?language=objc

Internal IDs:

• Bug 1556
• Bug 1555

Describe the bug
リポジトリにCOCOAの初回リリース以前に使われていたと思われる不要なファイルが含まれています

Expected behavior
純粋に不要なファイルのためユーザ影響などはありません(バイナリサイズにも当然影響ありません)が、
検索などの対象になってしまうので邪魔なものは取り除きたいです。

Additional context
わかっているものとしては以下のものがありますが網羅的に調べてはいないので過不足があるかもしれません

EN 以前の実装でバックグラウンド実行に使われていたらしいもの

Covid19Radar.Android/BackgroundService/

その他 UnUsed ディレクトリ

Covid19Radar/Behaviors/UnUsed
Covid19Radar/Converters/UnUsed
Covid19Radar/Model/UnUsed
Covid19Radar/Templates/UnUsed
Covid19Radar/ViewModels/HomePage/UnUsed
Covid19Radar/ViewModels/Tutorial/UnUsed
Covid19Radar/ViewModels/UnUsed
Covid19Radar/Views/HomePage/UnUsed
Covid19Radar/Views/Tutorial/UnUsed
Covid19Radar/Views/UnUsed
Covid19Radar.Android/Services/UnUsed
Covid19Radar.iOS/Services/UnUsed

Describe the bug
各種日付がロケール依存のフォーマットで保存される為、ロケールの設定が変わると正常に取得できない。

具体的な不具合として 2021/03/09 に利用開始した場合、2021/09/03 と判断されそれまでに改訂されたプライバシーポリシーポリシーの更新はすべて無視されると言う例が挙げられます。

対象と思われるデータ

1. startDateTime
2. PrivacyPolicyLastUpdateDateTime
3. TermsOfServiceLastUpdateDateTime

上記の内、 1, 2 に付いては GB ロケールで保存し、JP ロケールで表示させることで不正な値となることが #49 にて確認されています。
3 に付いても同様と思われますが、現在アプリケーション内で使われていません。

To Reproduce

1. スマートフォンにて GB ロケールを選択
   • Android は言語設定にて English ( United Kingdam ) を選択
   • iOS は「言語と地域」にて地域を変更
2. COCOA をインストール・起動し、利用規約・プライバシーポリシーに同意
3. スマートフォンにて JP ロケールを選択
4. COCOA を起動

Screenshots

Android の言語設定

GB ロケールにて起動後

JP ロケールに変更後、起動

Smartphone (please complete the following information):

• Device: [Any]
• OS: [iOS/Android]
• Version [1.2.2]

Additional context

COCOA 1.2.2 でデータの保存方法が変わったことが切っ掛けの可能性があります。
上記ロケール以外でのテストはしていません。

その機能リクエストは何らかの問題に関連しますか / Is your feature request related to a problem?

ソースコードを閲覧している時に、型や関数の役割・動作が分かりにくい時があります。
また、詳細な仕様もソースコードから推測する必要があります。

解決策についてお書きください / Describe the solution you'd like

プロジェクトファイルに <GenerateDocumentationFile>true</GenerateDocumentationFile> を追加した上で、型、関数、変数等に文書コメントを付記し、役割・動作を明確に分かる様にします。
コメントを付記する範囲は C# コンパイラからの警告が発生するもののみでも構わないと思います。

あなたが考える代替案についてご説明ください / Describe alternatives you've considered

今の所はありません。

その他 / Additional context

Internal IDs:

• NFR 2947

その機能リクエストは何らかの問題に関連しますか / Is your feature request related to a problem?

ライブラリーの追加や削除などによってライセンスファイルの記述に変更があった場合、どのように管理するか方針を決める必要がある。

#9 でやりとりした結果、現状は利用しないライセンス関係のファイルがアプリのリソースに含まれていることがわかった。

ライブラリーの追加や削除によってライセンスファイルの更新は必要になるので、ライセンスの記述に変更がある場合「どこを変更すればいいのか」を明確にして、あらかじめコントリビューターに知らせた方が良い。

解決策についてお書きください / Describe the solution you'd like

ライセンスの更新があっときに、どのファイルを変更するかを定めて、わかりやすい場所に記載する。

あなたが考える代替案についてご説明ください / Describe alternatives you've considered

Androidアプリなら自動的に使っているOSSライブラリーを検索して、ライセンスやCopyrightを作成してくれるプラグインがあるけど、Xamarinではよく知らないのでまた調べてみます。

• License Tools Plugin for Android: https://github.com/cookpad/LicenseToolsPlugin
• OSS Licenses Gradle Plugin: https://github.com/google/play-services-plugins/tree/master/oss-licenses-plugin

Internal IDs:

• Feature 2942
• NFR 2860
• NFR 2290
• NFR 1470

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
不具合対応を行う際に、どの機種でどのOSでどのバージョンで不具合が発生しているかを切り分けるためにiOSかAndroidかなどOSの情報とアプリのバージョンをデフォルトで付与できるようにしたい。

Describe the solution you'd like
A clear and concise description of what you want to happen.
InqueryPageViewModelのBodyの本文の前に差し込まれるようにしたい

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
GMSに対応していない機種などもあるので、そのあたりの方からのお問い合わせが発生したときにシステムの不具合なのか、仕様上仕方がないことなのかに切り分ける必要がある。

Additional context
Add any other context or screenshots about the feature request here.

• 現状

• 追加したいもの
  以下の例のように本文との間に環境情報を追加する

現在通知サーバーから配信されているファイルではtransmission_risk_levelに0が設定されていますが、
AndroidではtransmissionRiskScoreがExposureConfigurationに従って設定されるのはtransmission_risk_levelが1～8の場合であり、
0だった場合はtransmissionRiskScoreには1が入るようになっているようです。
https://github.com/google/exposure-notifications-internals/blob/7dadb83aa5c4b02ed4ae98cd8cf13f89b96962d2/exposurenotification/src/main/java/com/google/samples/exposurenotification/matching/RiskScoreCalculator.java#L69-L72

transmissionRiskScoreが1のときにriskScoreがminimumRiskScore以上になることはないので、
transmission_risk_levelが0だと、現在のAndroid版では接触が検知されることはないと思われます。

Is your feature request related to a problem? Please describe.
接触感染アプリ操作中に、アプリを切り替えずに新型コロナウイルスに関する最新情報を素早く確認する事ができれば、より便利になると思います。

Describe the solution you'd like
統計情報の表示機能、検索機能、と情報を探しやすいリンク集を持つページを作成します。
#37 の様なページです。

Describe alternatives you've considered
新たなページを作成するのではなく、ホーム画面から確認できる様にしても良いかもしれません。

ご検討の程宜しくお願い致します。
Takym

Internal IDs:

• PBI 2915

公開されている接触確認アプリの仕様書とこちらのレポジトリのコードを照らし合わせると、
陽性診断された方から送付された処理番号の扱いが不適切に実装されているように見えます。

処理番号について、プライバシーポリシーには下記の記載があります。

接触確認アプリケーションプライバシーポリシー
３.厚生労働省が取得する情報の利用目的及び利用方法

(1) 処理番号
処理番号は、入力された処理番号が陽性者に対して発行されたものであるか否かの確認が完了した後、アプリ、通知サーバー及び管理システムのそれぞれにおいて、直ちに削除されます。

記載されている利用方法は、システム仕様書では下記機能が該当するものと思われます。

接触確認アプリ及び関連システム仕様書
第2編 仕様(要件定義)

第1章 機能要件の定義

1. 機能に関する事項

3. 認証

これらの記述を総合すると、処理番号は認証機能による確認が完了した時点で削除されるべきと認識しております。

しかし、クライアントから通知サーバーに対して処理番号を送付した後の処理（下記 1〜4）をたどると
処理番号は確認完了後も削除されずに、他の情報と共にDBに保存されているように見えます

1. クライアントから呼ばれる陽性者登録API
   https://github.com/cocoa-mhlw/cocoa/blob/master/src/Covid19Radar.Api/DiagnosisApi.cs#L52

2. 感染者システムによる処理番号の確認処理（仕様書では認証機能）と思われる箇所
   https://github.com/cocoa-mhlw/cocoa/blob/master/src/Covid19Radar.Api/DiagnosisApi.cs#L98

3. 確認完了後、SubmitDiagnosisAsync関数の呼び出し
   https://github.com/cocoa-mhlw/cocoa/blob/master/src/Covid19Radar.Api/DiagnosisApi.cs#L108

4. SubmitDiagnosisAsync関数内、処理番号を含むデータをDBへ保存している
   https://github.com/cocoa-mhlw/cocoa/blob/master/src/Covid19Radar.Api.Common/DataAccess/CosmosDiagnosisRepository.cs#L50

SubmitDiagnosisAsync関数の呼び出しと、DBへの保存処理は削除したほうが適切ではないでしょうか。
仕様書やコードの読み違えなどしておりましたら申し訳ありません。

その機能リクエストは何らかの問題に関連しますか / Is your feature request related to a problem?

#41 に関連して、アプリケーションのサイズが多い理由として、重複する画像リソースが含まれていることが挙げられます。

言語に依存しない画像を削除することで、アプリケーションパッケージをよりコンパクトにできると考えます。

解決策についてお書きください / Describe the solution you'd like

重複したリソース全部消す。

Androidの仕様上、リソース修飾子を元にResourceManagerが端末や端末の設定に適したリソースを検索します。

• drawable-xxhdpi
  • image1.png
• drawable-xxhdpi-ja
  • image1.png

この場合、image1.pngが同じ内容である場合、drawable-xxhdpi-jaのimage1.pngは削除できます（drawable-xxhdpiのimage1.png）が選択される。

iOSもほぼ同様でBase.lprojを基準に、差し替えの必要な画像リソースだけを選択する仕組みがあります。

あなたが考える代替案についてご説明ください / Describe alternatives you've considered

ありません。

Internal IDs:

• NFR 1789
• NFR 1788

Describe the bug
スプラッシュ画面に表示されるシンボルマークが、オリジナルと比較して縦に長く、また、下部については左と右のパーツの間隔が広くなっている。

https://github.com/cocoa-mhlw/cocoa/blob/master/Covid19Radar/Covid19Radar.Android/Resources/drawable-en-xxhdpi/SplashImg.png

To Reproduce
Steps to reproduce the behavior:

1. アプリを起動する
2. スプラッシュ画面に表示された厚生労働省のロゴを見る

Expected behavior
厚生労働省のシンボルのアスペクト比・デザインがシンボルマークとキャッチフレーズについてに掲載されているものと一致する

Screenshots
オリジナルのシンボルマークを透過して重ねています。

Smartphone (please complete the following information):
スクリーンショットはAndroidのものですが、リソース画像を見る限りiOSも同様と考えます。

Additional context
リソース画像の段階でアスペクト比が変わっているようです。下部の間隔については編集の際に切れてしまったと言う雰囲気です。

また、右側の厚生労働省のロゴもわずかですが縦に長いと感じています。

Internal Tracking ID: BUG 1765

マージしなくても構いませんが、下記の様に大幅に改変しました事を報告させていただきます。
https://github.com/Takym/Covid19Radar
お忙しい中大変恐縮ですが評価の程宜しくお願いします。

https://qiita.com/shu223/items/7c4e87c47eca65724305#accuracy%E7%B2%BE%E5%BA%A6%E3%81%AE%E8%A8%88%E7%AE%97
これを見ると

beaconservice.csの
data.MinDistance = (beacon.Accuracy < data.MinDistance ? beacon.Accuracy : data.MinDistance);
data.MaxDistance = (beacon.Accuracy > data.MaxDistance ? beacon.Accuracy : data.MaxDistance);
は誤解してると心配しますが

Describe the bug
Xamarin.Androidを11.2.0.21にアップデートすると、ビルド後に実機／エミュレーターでデバッグ実行するときにCommand too longが発生する。

Time Elapsed 00:00:09.10
    /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.Debugging.targets(590,5): error : Command too long
    /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.Debugging.targets(590,5): error :   at Mono.AndroidTools.Adb.AdbClient.GetCommandBuffer (System.String command) [0x0006d] in /Users/builder/azdo/_work/278/s/xamarin-android/external/monodroid/tools/msbuild/external/androidtools/Mono.AndroidTools/Adb/AdbClient.cs:265 
    /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.Debugging.targets(590,5): error :   at Mono.AndroidTools.Adb.AdbClient.BeginWriteCommand (System.String command, System.AsyncCallback callback, System.Object state) [0x00006] in /Users/builder/azdo/_work/278/s/xamarin-android/external/monodroid/tools/msbuild/external/androidtools/Mono.AndroidTools/Adb/AdbClient.cs:227 
    /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.Debugging.targets(590,5): error :   at Mono.AndroidTools.Adb.AdbClient.BeginWriteCommandWithStatus (System.String command, System.AsyncCallback callback, System.Object state) [0x0000a] in /Users/builder/azdo/_work/278/s/xamarin-android/external/monodroid/tools/msbuild/external/androidtools/Mono.AndroidTools/Adb/AdbClient.cs:275 
    /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.Debugging.targets(590,5): error :   at System.Threading.Tasks.TaskFactory`1[TResult].FromAsyncImpl[TArg1] (System.Func`4[T1,T2,T3,TResult] beginMethod, System.Func`2[T,TResult] endFunction, System.Action`1[T] endAction, TArg1 arg1, System.Object state, System.Threading.Tasks.TaskCreationOptions creationOptions) [0x000f9] in /Users/builder/jenkins/workspace/build-package-osx-mono/2020-02/external/bockbuild/builds/mono-x64/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/FutureFactory.cs:919 
    /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.Debugging.targets(590,5): error :   at System.Threading.Tasks.TaskFactory.FromAsync[TArg1] (System.Func`4[T1,T2,T3,TResult] beginMethod, System.Action`1[T] endMethod, TArg1 arg1, System.Object state, System.Threading.Tasks.TaskCreationOptions creationOptions) [0x00000] in <36514b14425c4337b446653c547aa9c3>:0 
    /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.Debugging.targets(590,5): error :   at Mono.AndroidTools.Internal.AdbClientTaskExtensions.WriteCommandWithStatusAsync (Mono.AndroidTools.Adb.AdbClient client, System.String command, System.Threading.Tasks.TaskCreationOptions options) [0x00000] in /Users/builder/azdo/_work/278/s/xamarin-android/external/monodroid/tools/msbuild/external/androidtools/Mono.AndroidTools/Internal/AdbClientTaskExtensions.cs:62 
    /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.Debugging.targets(590,5): error :   at Mono.AndroidTools.AndroidDevice+<>c__DisplayClass62_0.<RunShellCommand>b__0 (System.Threading.Tasks.Task t) [0x0000f] in /Users/builder/azdo/_work/278/s/xamarin-android/external/monodroid/tools/msbuild/external/androidtools/Mono.AndroidTools/AndroidDevice.cs:403 
    /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.Debugging.targets(590,5): error :   at System.Threading.Tasks.ContinuationResultTaskFromTask`1[TResult].InnerInvoke () [0x00024] in <36514b14425c4337b446653c547aa9c3>:0 
    /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.Debugging.targets(590,5): error :   at System.Threading.Tasks.Task.Execute () [0x00000] in /Users/builder/jenkins/workspace/build-package-osx-mono/2020-02/external/bockbuild/builds/mono-x64/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2319 
Done building target "_Upload" in project "Covid19Radar.Android.csproj" -- FAILED.

Done building project "Covid19Radar.Android.csproj" -- FAILED.

Build FAILED.

/Users/keiji_ariyama/.nuget/packages/msbuild.sdk.extras/2.0.54/Sdk/Sdk.props(25,3): warning MSB4011: "/usr/local/share/dotnet/sdk/5.0.201/Sdks/Microsoft.NET.Sdk.WindowsDesktop/targets/Microsoft.NET.Sdk.WindowsDesktop.props" cannot be imported again. It was already imported at "/usr/local/share/dotnet/sdk/5.0.201/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.props (148,3)". This is most likely a build authoring error. This subsequent import will be ignored. [/Users/keiji_ariyama/cocoa/Covid19Radar/Xamarin.ExposureNotification/Xamarin.ExposureNotification.csproj]
/Users/keiji_ariyama/.nuget/packages/msbuild.sdk.extras/2.0.54/Sdk/Sdk.props(25,3): warning MSB4011: "/usr/local/share/dotnet/sdk/5.0.201/Sdks/Microsoft.NET.Sdk.WindowsDesktop/targets/Microsoft.NET.Sdk.WindowsDesktop.props" cannot be imported again. It was already imported at "/usr/local/share/dotnet/sdk/5.0.201/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.props (148,3)". This is most likely a build authoring error. This subsequent import will be ignored. [/Users/keiji_ariyama/cocoa/Covid19Radar/Xamarin.ExposureNotification/Xamarin.ExposureNotification.csproj]
/Users/keiji_ariyama/.nuget/packages/msbuild.sdk.extras/2.0.54/Sdk/Sdk.props(25,3): warning MSB4011: "/usr/local/share/dotnet/sdk/5.0.201/Sdks/Microsoft.NET.Sdk.WindowsDesktop/targets/Microsoft.NET.Sdk.WindowsDesktop.props" cannot be imported again. It was already imported at "/usr/local/share/dotnet/sdk/5.0.201/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.props (148,3)". This is most likely a build authoring error. This subsequent import will be ignored. [/Users/keiji_ariyama/cocoa/Covid19Radar/Xamarin.ExposureNotification/Xamarin.ExposureNotification.csproj]
/Users/keiji_ariyama/.nuget/packages/msbuild.sdk.extras/2.0.54/Sdk/Sdk.props(25,3): warning MSB4011: "/usr/local/share/dotnet/sdk/5.0.201/Sdks/Microsoft.NET.Sdk.WindowsDesktop/targets/Microsoft.NET.Sdk.WindowsDesktop.props" cannot be imported again. It was already imported at "/usr/local/share/dotnet/sdk/5.0.201/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.props (148,3)". This is most likely a build authoring error. This subsequent import will be ignored. [/Users/keiji_ariyama/cocoa/Covid19Radar/Xamarin.ExposureNotification/Xamarin.ExposureNotification.csproj]
/Applications/Visual Studio.app/Contents/Resources/lib/monodevelop/bin/MSBuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2143,5): warning MSB3277: Found conflicts between different versions of "System.Numerics.Vectors" that could not be resolved.  These reference conflicts are listed in the build log when log verbosity is set to detailed.
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.Debugging.targets(590,5): error : Command too long
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.Debugging.targets(590,5): error :   at Mono.AndroidTools.Adb.AdbClient.GetCommandBuffer (System.String command) [0x0006d] in /Users/builder/azdo/_work/278/s/xamarin-android/external/monodroid/tools/msbuild/external/androidtools/Mono.AndroidTools/Adb/AdbClient.cs:265 
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.Debugging.targets(590,5): error :   at Mono.AndroidTools.Adb.AdbClient.BeginWriteCommand (System.String command, System.AsyncCallback callback, System.Object state) [0x00006] in /Users/builder/azdo/_work/278/s/xamarin-android/external/monodroid/tools/msbuild/external/androidtools/Mono.AndroidTools/Adb/AdbClient.cs:227 
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.Debugging.targets(590,5): error :   at Mono.AndroidTools.Adb.AdbClient.BeginWriteCommandWithStatus (System.String command, System.AsyncCallback callback, System.Object state) [0x0000a] in /Users/builder/azdo/_work/278/s/xamarin-android/external/monodroid/tools/msbuild/external/androidtools/Mono.AndroidTools/Adb/AdbClient.cs:275 
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.Debugging.targets(590,5): error :   at System.Threading.Tasks.TaskFactory`1[TResult].FromAsyncImpl[TArg1] (System.Func`4[T1,T2,T3,TResult] beginMethod, System.Func`2[T,TResult] endFunction, System.Action`1[T] endAction, TArg1 arg1, System.Object state, System.Threading.Tasks.TaskCreationOptions creationOptions) [0x000f9] in /Users/builder/jenkins/workspace/build-package-osx-mono/2020-02/external/bockbuild/builds/mono-x64/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/FutureFactory.cs:919 
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.Debugging.targets(590,5): error :   at System.Threading.Tasks.TaskFactory.FromAsync[TArg1] (System.Func`4[T1,T2,T3,TResult] beginMethod, System.Action`1[T] endMethod, TArg1 arg1, System.Object state, System.Threading.Tasks.TaskCreationOptions creationOptions) [0x00000] in <36514b14425c4337b446653c547aa9c3>:0 
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.Debugging.targets(590,5): error :   at Mono.AndroidTools.Internal.AdbClientTaskExtensions.WriteCommandWithStatusAsync (Mono.AndroidTools.Adb.AdbClient client, System.String command, System.Threading.Tasks.TaskCreationOptions options) [0x00000] in /Users/builder/azdo/_work/278/s/xamarin-android/external/monodroid/tools/msbuild/external/androidtools/Mono.AndroidTools/Internal/AdbClientTaskExtensions.cs:62 
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.Debugging.targets(590,5): error :   at Mono.AndroidTools.AndroidDevice+<>c__DisplayClass62_0.<RunShellCommand>b__0 (System.Threading.Tasks.Task t) [0x0000f] in /Users/builder/azdo/_work/278/s/xamarin-android/external/monodroid/tools/msbuild/external/androidtools/Mono.AndroidTools/AndroidDevice.cs:403 
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.Debugging.targets(590,5): error :   at System.Threading.Tasks.ContinuationResultTaskFromTask`1[TResult].InnerInvoke () [0x00024] in <36514b14425c4337b446653c547aa9c3>:0 
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.Debugging.targets(590,5): error :   at System.Threading.Tasks.Task.Execute () [0x00000] in /Users/builder/jenkins/workspace/build-package-osx-mono/2020-02/external/bockbuild/builds/mono-x64/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2319 
    5 Warning(s)
    1 Error(s)

To Reproduce
再現試験はお薦めしない。
一度この現象が発生すると、不具合のないXamarin.Androidに更新（ダウングレード含む）を行うまで現象は改善しない。

Steps to reproduce the behavior:

1. Xamarin.Androidを11.2.0.21にアップデートする（更新通知から。または最新版のVisual Studio for Macをインストールする）
2. COCOAのソリューションを開きConfigurationをDebugまたはDebug_Mockに変えてエミュレーター／実機でデバッグを実行
3. See error

Expected behavior
エミュレーター／実機でアプリが起動してデバッグできる

Desktop (please complete the following information):

• OS: macOS 11.2.3
• Visual Studio for Mac 8.9.1

Xamarin.Android
Version: 11.2.0.21 (Visual Studio Community)
Commit: xamarin-android/d16-9/93eab59
Android SDK: /Users/keiji_ariyama/Library/Android/sdk
	Supported Android versions:
		5.1 (API level 22)

SDK Tools Version: 26.1.1
SDK Platform Tools Version: 31.0.0
SDK Build Tools Version: 30.0.2

Build Information: 
Mono: 5e9cb6d
Java.Interop: xamarin/java.interop/d16-9@d6d86b2
ProGuard: Guardsquare/proguard/v7.0.1@912d149
SQLite: xamarin/sqlite/3.34.1@daff8f4
Xamarin.Android Tools: xamarin/xamarin-android-tools/d16-9@9d8924d

Additional context
Stackoverflowに類似の報告が見つかっている。

In Visual Studio 16.9.0 Android “deploy to device” error - Command too long
https://stackoverflow.com/questions/66465262/in-visual-studio-16-9-0-android-deploy-to-device-error-command-too-long

Android Build Optionの"Use Fast Deployment"を無効化にするという方法については試行したものの、そもそも現在のCOCOAに含まれるCovid19Radar.Androidプロジェクトでは"Use Fast Deployment"は無効になっている。しかし、Deployment時のログには「Fast Deployment」が記録されているので、オプション選択が正常に機能していない可能性がある。
また、"Use Fast Deployment"を有効にして「OK」ボタンでダイアログを閉じても、次にダイアログを開いた時には無効になっている。

結局、#40 (comment) と同様、Xamarin.Androidのバージョンを「 11.1.0.17 」にダウングレードして 解決した。 解決していないので引き続き情報を収集する。

アップデートは慎重に！！

その機能リクエストは何らかの問題に関連しますか / Is your feature request related to a problem?

デバッグ開発上の課題で一般ユーザーには関係がない。

デバッグ用とリリース用（Google Playから手に入る）COCOAのアイコンとアプリ名が同じなので、どちらを起動したら良いのかわからなくなる。また、リリース版（Google Play）を間違って消してしまうこともあり得る。

解決策についてお書きください / Describe the solution you'd like

Androidアプリ開発ではデバッグ版とリリース版で、アプリのアイコンやアプリ名（文字列リソース）を分けることがあるのでそれをしたい（iOS版との並行開発でも見たことがあるので、比較的一般的な施策だと考える）。

あなたが考える代替案についてご説明ください / Describe alternatives you've considered

このリポジトリのアイコンとアプリ名をリリース用とまったく違ったものにする（開発用の仮アイコンにする）、リリース作業の一環としてでCOCOAのアイコンとアプリ名に差し替えてもらう。

その他 / Additional context

AndroidアプリのBuild Flavor的な機能をXamarinで探しましたが、そこまで簡単にはいかなさそうです。

https://stackoverflow.com/questions/54941860/product-flavor-in-xamrin-android

Internal IDs:

• NFR 2411

Android版のバックグラウンド処理（WorkManager）においてExistingPeriodicWorkPolicy にExistingPeriodicWorkPolicy.Replaceの値を指定しています。

これはGoogleが提供しているドキュメントExposure Notifications implementation guideに基づいた記述と推測しますが、当該ドキュメントは2020年9月に更新されており、現在はExistingPeriodicWorkPolicyにはExistingPeriodicWorkPolicy.KEEPを指定するように記述が変更されています。

// Use a unique work to avoid multiple workers.
workManager.enqueueUniquePeriodicWork(
    PROVIDE_KEY_WORK_NAME,
    ExistingPeriodicWorkPolicy.KEEP,
    workRequest
)

ドキュメントの更新履歴によれば、ExistingPeriodicWorkPolicy.Replaceを指定した場合、WorkManagerがシステムのJobSchedulerにジョブを追加しない問題が起こることがある。とのことです。

This resolves an issue with WorkManager sometimes not adding a job to the system job scheduler.

最新のドキュメントの内容に基づいて、当該部分をExistingPeriodicWorkPolicy.KEEPに変更することを強くお勧めします。

アプリの設定画面から参照されているライセンスファイル内に「Json.net」というドメインへのリンクが含まれていますが、こちらはサードパーティライブラリの名称であり、リンクとして扱うべきドメイン名ではないように思われます。

• アプリが参照しているHTMLファイル
  <h2 id="jsonnet"><a href="http://Json.NET">Json.NET</a></h2>

• プロジェクト内の元ファイル
  

  cocoa/Covid19Radar/Covid19Radar/Resources/html/license.html

  Line 101 in 97e042e

  <h2 id="jsonnet"><a href="http://Json.NET">Json.NET</a></h2>

他のライブラリにおいてもライブラリ名にリンクは設定されていないため、意図したものでなければこちらのリンクは削除した方が良いのではないでしょうか。

Internal IDs:

• NFR 1470

Describe the bug

Android端末の言語設定が英語の場合、COCOA起動時に「プライバシーポリシーの改定」画面を経由しない

To Reproduce

• プライバシーポリシー改定以前から使用し、改定の確認を行っていない環境を用意する
• 端末の言語設定を「日本語 (日本)」に変更する
• COCOAを起動する
• 「プライバシーポリシーの改定」画面が表示される
• 「確認しました」をタップせずにCOCOAを強制終了する
• 端末の言語設定を「English (United Kingdom)」に変更する
• COCOAを起動する
• 「プライバシーポリシーの改定」画面が表示されずにCOCOAのホーム画面に遷移する

Expected behavior

端末の言語設定にかかわらず「プライバシーポリシーの改定」に相当する画面による確認を経てからCOCOAが動作する

Smartphone (please complete the following information):

• Device: SH-M08
• OS: Android 10
• COCOA Version: 1.2.2

Additional context

「プライバシーポリシーの改定」画面を表示しない場合に旧プライバシーポリシーに沿った動作をしているのであれば、問題ありません。

不具合の内容 / Describe the bug

COCOA に置いて Xamarin.ExposureNotification は古いバージョンの物をリポジトリ内にコピーして利用しています。
このバージョンでは、ExposureInfo.Timestamp から取得出来る時刻データが、Android では UTC 、iOS では LocalTime であるというバグがあります。

COCOA としてはどちらもUTCとして扱っているようで、iOS 版を日本時間で利用していると日付表示時に９時間ずれて表示される事となります。

表示部分のコード。iOS 版では結果的に ToLocalTime() を二回通すため誤った日付が表示される。

再現手順 / Steps to reproduce

1. iOS / Android 環境を用意し、日本時間でCOCOAの利用を開始する
2. 各端末で、15時〜24時の9時間の間に iOS / Android それぞれで接触がある状態にする
3. 接触させた端末のうち、でAndroid 側で感染登録を行う
4. 感染チェックのタスクが走った後、COCOAを起動し陽性者との接触を確認するボタンで遷移すると接触した日付の翌日が表示される。

上記の iOS , Android を逆にして実行すると接触した日付が表示される。

期待される挙動 / Expected behavior

Android と同様、接触した日付が表示される。

スクリーンショット / Screenshots

実機でのテストを行う環境が構築できないため、ありません。

動作環境 / Environments

• デバイス：（実機でのテスト無し）
• OS：(iOS）
• バージョン：(all)

その他 / Additional context

解決策

1. PR #1 を取り込む
2. Xamarin.ExposureNotification を 0.13.0-preview 以降に更新する

Xamarin.ExposureNotification のオリジナルにおける修正と、PR #1 は @moonmile 氏による物で修正内容は同一です。

当方で再現環境が用意できないため、エミュレーター・実機による再現テストは行っていません。
念の為、現バージョン（1.2.2）での再現テストを推奨します。

This Issue was written with the help of @zipperpull .

厚生労働省のシンボルマークを含む画像を使用していますが、厚生労働省のシンボルマークには使用条件があります。
https://www.mhlw.go.jp/kouseiroudoushou/symbol/shiyou.html

COCOAはMPL 2.0となっていますが、厚生労働省のシンボルマークを含む画像もMPL 2.0で良いですか？

参考: Covid-19Radar/Covid19Radar#653

• 1: Confirmed test (Low)
• 2: Confirmed test (Standard)
• 3: Confirmed test (High)
• 4: Confirmed clinical diagnosis
• 5: Self report
• 6: Negative case
• 7: Recursive case

に従っているのでしょうか？それとも独自の意味付けをされているのでしょうか？
独自設定なのであれば(ソース上に何らかのコメントは欲しいですが)、以下の提案は無視してcloseしてください。

現在サーバ側で4固定となっているtransmission_risk_levelですが、3にしたほうがよいのではないでしょうか？
理由は三点

1. 陽性者は必ず PCR等の検査を受けているため
2. GAEN v2 におけるレポートタイプとの整合性をとるため
3. 発症日を基準とした感染性の高さを考慮するため

です。

1 について
https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/kenkou_iryou/dengue_fever_qa_00004.html#Q2
https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/0000121431_00132.html
によると、陽性確定には PCR等の検査が必須です。

2 について
https://developers.google.com/android/exposure-notifications/exposure-notifications-api
ではTemporaryExposureKey#reportTypeは以下のように定義されています。

1: CONFIRMED_TEST. A medical provider has confirmed the user had a positive diagnostic test for COVID-19.
2: CONFIRMED_CLINICAL_DIAGNOSIS. A medical provider has confirmed the user had symptoms consistent with a COVID-19 diagnosis.

将来 v2 に移行されるのでしょうから、transmission_risk_levelとレポートタイプを合わせておいたほうが良いように思います。

3 について
Confirmed testが3種類定義されているのは、発症日を基準とした感染性の高さに応じてTransmissionRiskScoreを変更できるようにするためだと思われます。
例えば、

• Low: 発症日-14日〜-6日および+11日〜+14日
• Standard: 発症日-5日〜-3日および+6日〜+10日
• High: 発症日-2日〜+5日

といった具合です。
現在の COCOA は積極的疫学調査との整合性を取るために、発症日-2日(厳密には2日と21時間)から登録日前日までのTEKをサーバに送信していますが、この期間は感染性の高い期間に相当するのではないかと思います。

これらの理由により、transmission_risk_levelには現在の4ではなく3を当てるのが妥当ではないかと考えております。

どの値を選んでもリスク値に変化はないのですが、それがそうである意味を明確にして頂けたらと思います。

Describe the bug
Android 版 v1.2.2 においてバックグラウンドタスク実行時の設定マイグレーションに失敗するケースが有る

Smartphone (please complete the following information):

• Device: [Android]
• OS: [all]
• Browser [none]
• Version [1.2.2]

Additional context

v1.2.2 から UserData の保持方法が変更になりました。
この際、旧バージョンからのデータを Migrate する処理が追加になっています。

アプリをv1.2.2にアップデート後、一度でも起動すればこの処理が行われ正常にマイグレーションが行われますが、
Android においてバックグラウンドタスクから呼び出した場合、Application.Current が参照出来ないためマイグレーションに失敗します。
（ Xamarin.Forms の初期化が行われていない為と思われる ）

想定している前提条件
v1.2.2 以前にWorkerManagerにタスクが登録され、v1.2.2 アップデート後に同タスクが実行される状態である事
（確実にそうなるかは自信が無いので情報をお持ちの方は補足をお願いしたいです）

当 Issue は #30 内の指摘から単独のIssueとして切り出したものです。
Android 開発には不慣れなため、間違い等多々あると思いますのでその際は指摘をお願い致します。

Describe the bug

ヘッダロゴ中、厚生労働省さんの英語名表記にスペルミス (Welfar) があります。

To Reproduce

1. COCOA を起動する
2. メインページ上部のヘッダロゴを見る

Expected behavior

正しいスペル (Welfare) でロゴが表示される。

Smartphone (please complete the following information):

• Device: Essential Phone PH-1
• OS: Android 10
• Version: 1.2.2

Internal Tracking ID: BUG 1763

Is your feature request related to a problem? Please describe.
Issue / Pull Request テンプレートが英語のみ。

Describe the solution you'd like
Issue / Pull Request テンプレートが英語のみなので、日本語を併記する。Issue Template に Custom Template が残っているので削除。