PullRequest #30 について実験した結果です。

• バックグランドタスクの実行間隔を6時間（現在のCocoaに設定されている値）に設定
• Mock_Debugビルドしたバイナリを実機（Pixel 3/API Level 30）にインストール
• バッテリー駆動の状態で放置

実行間隔が8時間から13時間とムラはあるものの、定期的な実行ができていることが確認できました。

"2021/03/03 01:13:16" "2021/03/03 09:17:25" "2021/03/03 15:18:41" "2021/03/04 04:34:32" "2021/03/04 15:51:45"

ログを置いておきます。

https://gist.github.com/keiji/3b3b4ee48b08ec61cd90b7cba70bf287

Here's the solution that worked for me

check both the checkboxes I checked under Build Tab.

If I interleave non-bitcode and bitcode input object files, then gold seems to insert its LTO object file at the first bitcode input file. (I don't know where in gold this logic is implemented.)

CC=/x/android-ndk-r22/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android21-clang
echo 'void FUNC() {}' >test.c
$CC test.c -c -o test1.o -DFUNC=func1
$CC test.c -c -o test2.o -DFUNC=func2
$CC test.c -c -o test3.o -DFUNC=func3 -flto
$CC test.c -c -o test4.o -DFUNC=func4
$CC test.c -c -o test5.o -DFUNC=func5
$CC test.c -c -o test6.o -DFUNC=func6 -flto
$CC test.c -c -o test7.o -DFUNC=func7
$CC test.c -c -o test8.o -DFUNC=func8
$CC -flto -fuse-ld=gold -O2 -Wl,-Map,a.map -fpic -shared test[12345678].o
cat a.map

layout of .text:

.text           0x0000000000000640       0x5c
 .text          0x0000000000000640       0x3c /x/android-ndk-r22/toolchains/llvm/prebuilt/linux-x86_64/bin/../sysroot/usr/lib/aarch64-linux-android/21/crtbegin_so.o
                0x0000000000000654                __atexit_handler_wrapper
                0x000000000000064c                __emutls_unregister_key
                0x0000000000000660                atexit
 .text          0x000000000000067c        0x4 test1.o
                0x000000000000067c                func1
 .text          0x0000000000000680        0x4 test2.o
                0x0000000000000680                func2
 .text          0x0000000000000684        0x0 /tmp/lto-llvm-c4c213.o
 .text.func3    0x0000000000000684        0x4 /tmp/lto-llvm-c4c213.o
                0x0000000000000684                func3
 .text.func6    0x0000000000000688        0x4 /tmp/lto-llvm-c4c213.o
                0x0000000000000688                func6
 .text          0x000000000000068c        0x4 test4.o
                0x000000000000068c                func4
 .text          0x0000000000000690        0x4 test5.o
                0x0000000000000690                func5
 .text          0x0000000000000694        0x4 test7.o
                0x0000000000000694                func7
 .text          0x0000000000000698        0x4 test8.o
                0x0000000000000698                func8
 .text          0x000000000000069c        0x0 /x/android-ndk-r22/toolchains/llvm/prebuilt/linux-x86_64/bin/../sysroot/usr/lib/aarch64-linux-android/21/crtend_so.o

I see .init and .fini terminators in the glibc and musl crtn.o files, so if the LTO output has entries for those sections (e.g inline assembly?), then LTO breaks them:

$ cat >test.c <<EOF
#include <stdio.h>
void foo() { printf("foo!\n"); }
asm(".section .init,\"ax\",@progbits\ncall foo\n");
int main() {}
EOF
$ /x/clang+llvm-11.0.1-x86_64-linux-gnu-ubuntu-16.04/bin/clang test.c -O2 -fuse-ld=lld && ./a.out
foo!
$ /x/clang+llvm-11.0.1-x86_64-linux-gnu-ubuntu-16.04/bin/clang test.c -O2 -fuse-ld=lld -flto && ./a.out

The gold behavior seems better to me? (Before I tested it, I also guessed that it might use the last bitcode input.)

@keiji さん、遅くなりましたがご指摘ありがとうございます。

#25 #31 の対応に併せて、こちらも対応予定です。

ExistingPeriodicWorkPolicy.KEEP

に修正します。

また、コメントもありがとうございます。理想的なオープンソース開発にはまだ至れていないと思いますが、より良い開発プロセスを目指して進めていきたいと考えておりますので、今後ともよろしくお願いいたします。

@zipperpull ありがとうございます。いただいた内容も踏まえてテスト進めます。

こちらでは議論する意味もなさそうということになるのですがこの方針でよろしいのでしょうか？

最終確定というよりは実装・検証を進めている段階なので、その中でまた問題点あればこちらでも共有させていただきたいと思います。 また、#25 と混ぜて書いてしまいましたが、そちらと分けて扱うようにします。

https://github.com/cocoa-mhlw/cocoa/blob/cf58f2230ac5d26736334a52cf4b680725d8038d/src/Covid19Radar.Api/Models/V1DiagnosisSubmissionParameter.cs#L32 https://github.com/cocoa-mhlw/cocoa/blob/cf58f2230ac5d26736334a52cf4b680725d8038d/src/Covid19Radar.Api/Models/DiagnosisSubmissionParameter.cs#L43 について、Google/Apple がお勧めしている以下の意味付け

• 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を当てるのが妥当ではないかと考えております。

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

@tmurakami こちらご指摘ありがとうございます。遅くなりすみません。

悩ましいところだったのですが、利用規約上では、

二 「陽性者」とは、新型コロナウイルス感染症の陽性診断が確定した者をいいます。 としているため、今は4でセットしています。

ただ、API v2移行後も想定して検討しきれていたわけではなく、先のAndroid通知障害対応の過程で取り急ぎセットしたものでなので、v2移行時にまたご指摘の点について検討することになると思います。 またその際にディスカッションさせていただけると嬉しいです。

コードを見ていないのでなんともいえませんが、

バックグラウンド処理の場合は別処理でインスタンスをnewするよう実装

一般論としては、安易にこれをやるとバックグラウンドでプロセス起動されたあと MainActivity が起動された場合に問題がありうるとは思うのでテストなどでの考慮をよろしくお願いします。

また、実装進めていますということだとこちらでは議論する意味もなさそうということになるのですがこの方針でよろしいのでしょうか？ @heykuro

皆さま、レスポンス遅れましたがこちらありがとうございます。

いただいたご意見を参考にさせていただきながら今開発チームでも対応進めていますが、以下のような方針で進めています(PRをこちらに上げていないので説明ベースで分かりづらくすみませんが、中間的な共有として)。

問題点として、指摘いただいているXamarin.Formsが初期化されていない点について開発チームでも対応中です。 具体的には、Xamrin.Formsに依存している、Application.Current.Properpertiesは指摘いただいているようにバックグラウンド処理の際は初期化されていないので( @b-wind さんご指摘ありがとうございます)、その場合はXamarin.Formsの内部処理(Deserializer)を直接生成して呼ぶような形で回避するよう実装検討。

@zipperpull さんからいただいた、

v1.2.1 のユーザを切り捨てる判断ができるのであれば、3. の選択肢が一番楽なのかもしれません。

という点については、切り捨ては考えておらず、Migrateが実行できる形での対応を考えています。

また、これも既に指摘いただいているように、このissueで指摘されている点だけでなく、DependencyServiceの問題についても対応します( #25 で指摘されている内容)。 通常起動されているときはDependencyServiceでインスタンス取得するが、バックグラウンド処理の場合は別処理でインスタンスをnewするよう実装する形です。

前言撤回してすみません。

v1.2.2 の修正のとき、サーバ側の以下のコミットで v1 API (v1.2.1 以前で使っている？)の transmissionRiskLevel も 4 に書き換えてしまっていますね。。

https://github.com/cocoa-mhlw/cocoa/commit/cf58f2230ac5d26736334a52cf4b680725d8038d#diff-26d2c0fba561e4cc742d58a1ec6a1b6250dfed3654da595d72e0dcc4efa35ccaR32

そうなると、v1.2.1 以前のユーザでも現時点では MainActivity 起動時のチェックで通知が行われるパターンがあるのかもしれないですね？

すくなくとも v1.2.1 は transmission_risk_level の問題で誰も通知が出ていない

そういえばそうでしたね。 失念していました。 であれば個人的には 2 が良いように思います。

すくなくとも v1.2.1 は transmission_risk_level の問題で誰も通知が出ていないのでそれは問題ないかなと思っています(v1.1.3 とかの古いもので表示されるパターンまでは考えていないですがさすがにたぶん大丈夫ではないかと。。)

DependencyService の問題を解決しないといずれにしても Worker からの起動がうまくいかないので、 この不具合だけ直すのはたぶん意味がなくて #25 を直す前提になると思います。

そうでしたね、すみません...

ただExposureNotificationHandlerの当該箇所で Migrate できないのであれば、スキップするしかないのではないかとも考えています。 LastProcessTekTimestampが復元できない場合、直近14日以内に接触通知を受けた v1.2.1 以前の利用者は更新後に再度同じ通知を受けてしまうのではないかと懸念しています。 (勘違いかも)

Hiding all symbols that don't need to be public is always a good idea. The linker is free to simplify relocations for hidden symbols because they cannot be interposed. You're paying for those symbols in app startup time by not doing that.

The change in the linked commit will not always work. If you encounter this error with a symbol that is part of your library's interface it will not work. If you encounter this issue with a symbol that is a part of your public interface you need a different fix (the fixes I mentioned earlier in this thread).

We're always happy to help where we can, but we can't fix code we don't have access to, and we can't offer advice without context.

DependencyService の問題を解決しないといずれにしても Worker からの起動がうまくいかないので、 この不具合だけ直すのはたぶん意味がなくて #25 を直す前提になると思います。 また、v1.2.2 で Worker が起動できている一部ユーザ(一部端末？)は、すでに必ず MainActivity -> SplashPage を経由して Migrate も終わっているので大丈夫ではないかと思います。

なので対象となるのは v1.2.1 以前のユーザがアップデートした場合で、 後続をスキップする場合は、アプリをアップデートしたまま一度も通常起動しないユーザは Worker だけ起動されてなにもしない状態になるので通知は受けられない状態になる可能性が出てきそうです。 (現状も通知は受けられない状態のユーザなので、悪化はしないかも)

ExposureNotificationHandlerの当該箇所では Migrate できているかどうかだけをチェックして、できていなかったら後続処理をスキップする、というのはどうでしょうか？ 今は毎日起動をお願いしている状況なので、この不具合だけ修正してすぐにリリースすれば良いように思います。

For those of you who still have the issue, take a look at this commit (google/boringssl@16e38b2).

This is what I love about github community, still manages to solve issues even when owners don't give a f. Thanks a lot @hanj73

やってみました。 少なくとも、containerRegistry.RegisterSingleton<ILoggerService, LoggerService>();を消した状態で、DependencyService.Resolve<ILoggerService>()のケースは動きました。

とするとcontainerRegistry.RegisterSingletonは全部消して、IfAlreadyRegistered.Replaceに戻してもいいわけですね…

これは消しても動く（RegisterCommonTypesで追加されたものは、DependencyService.Resolveでも解決できる）

イベントの入場条件に「COOCAのインストール後14日経過＋接触記録がないこと」が存在し、3 の使用日数のリセットは厳しいかもしれませんね。

https://twitter.com/ls_9mermaid/status/1354433072477786117

個人的には 1 か 2 が良いと思います。

2 に加えて、MainActivityを起動したタイミングで新しいバージョンのデータが存在していた場合、Application.Current.Propertiesからは使用開始日のデータに限定してMigrateする。のような手当をすると、実装負荷とユーザーへの影響のバランスが良いと考えます。

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

追試用に @keiji が作った検証コードの Xamarin.Forms 版を置いておきます。

AndroidBackTaskTest/RequiresDeviceIdleTest at main · moonmile/AndroidBackTaskTest

御意。現状の v1.2.2 で UserUuid は取り除かれているので、ここはクローズしていいと思います。

For those of you who still have the issue, take a look at this commit (https://github.com/google/boringssl/commit/16e38b2b8f50a3d048f61d2979d5ceddacd70fc3).

この問題の原因は以下のようになっていて

• v1.2.1 以前で利用していた Application.Current.Properties は Xamarin.Forms に依存している
• Android では WorkManager の Worker が起動するタイミングでは Xamarin.Forms が初期化されていない可能性があるので Properties は読み書きできない
  • MainActivity を起動後、OS側でプロセスが終了させられなかった場合のみ偶然動く

このため現状のままだと Migrate を Worker から実行すること自体が困難ということになりそうです。解決案としては、

1. Migrate の処理だけ Xamarin.Forms に依存せずに直接 Properties ファイルを読み込んで実行する
2. Worker から (ExposureNotificationHandler から) Migrate するのはあきらめて、MainActivity が実行されたタイミングで移行する
3. v1.2.1 以前からのアップデート後、Migrate 未実行で Worker が起動された場合は Migrate をあきらめる(使用日数も 0日になる)

という案がありそうです。1. は iOS との差分をどう処理するかの問題があり、2. は Worker で ExposureNotificationService が呼ばれて新しい PreferencesService / SecureStorageService にデータが保存されてしまうので、MainActivity 実行時には Properties とマージする処理が必要になります。

v1.2.1 のユーザを切り捨てる判断ができるのであれば、3. の選択肢が一番楽なのかもしれません。 ただし、Worker の Migrate を単に削除してしまうと、Worker で更新した Preferences/SecureStorage の情報が Migrate で上書きされる状況になるので、アップデート後に接触通知があったユーザは起動後情報が消えるなどの問題を起こす可能性もありそうです(未検証)。 回避するには、Migrate 実行済みのフラグを PreferencesService に保存するなどの対応追加が必要ではないかと思われます。

This is the wrong bug tracker. Go to https://developer.android.com/studio/report-bugs and follow the instructions for filing an Android Studio bug.

This is the wrong bug tracker. Go to https://developer.android.com/studio/report-bugs and follow the instructions for filing an Android Studio bug.

If you're getting an error that tells you to recompile with PIC then you either didn't recompile everything with PIC or you have non-PIC assembler code.

Is your feature request related to a problem? Please describe. This might be a bit out there but...

I want an easy CRI path when developing for platforms that only expose container runtimes. There seems to be a better way to go about doing this then having tens of thousands of man hours spent optimizing dockerfiles.

If I am using a LLVM frontend to create a service that runs on K8s all I am doing in my Dockerfile is starting from scratch and pulling in any dynamic libs I am depending on.

Alot of people struggle with this and end up using base images that happen to have the libs at some version.

Describe the solution you'd like I specify x86_64-unknown-linuxcri and have a container image. It pulls in the linked dependencies at runtime into the file layers.

Taking it further there is probably room for OCI runtime optimizations? Like if we scanned for sys call we could determine whether file mounts are read only.

Describe alternatives you've considered Building a container nowadays is pretty much limit to wrapping a pre-generated binary. So all work happens post-compilation. However, that's a design choice. One that makes container building very portable. You can take very far. But it is not convenient for the creator and results in sub-optimal images.

I could go frontend to frontend and make buildtools that user the buildkit api. Like so in rust:

                   OCI Crago Plugin Crate- --->Rust BuildKit-------------->Buildkit                                        
                      ^                                                             
                      |                                                             
                      |                                                             
User-----------------> Cargo--------------->OCI Image 

Additional context Inspiration for the idea: https://github.com/denzp/cargo-wharf

Wrong repository :D