mono
[URGENT] It takes 8 minutes to entirely launch application on only Android OS 8.1 Device with aar from Embeddinator.
We are already distributing our native Android application, and we are developing the new views & functions for our native Android application through the Xamarin. But we’d a problem that we’ve tried to apply the generated aar file from the Embeddinator to our native Android application. The problem is below.
Steps to Reproduce
1.Add below packages on Xamarin Android part.
Xamarin.Android.Support.v7.AppCompat Xamarin.Android.Support.v7.CardView Xamarin.Android.Support.v7.MediaRouter Xamarin.Android.Support.v7.Palette Xamarin.Android.Support.v7.RecyclerView
2.Generate aar file from Embeddinator.
3.Import generated aar file to native Android application.
4.Run the project.(It takes 8 minutes to entirely launch application on only Android OS 8.1 Device.)
For additional, If remove the packages on Xamarin Android part, our native Android application could launch normally on Android OS 8.1.
Problem
It takes 8 minutes to entirely launch application on only Android OS 8.1 Device. (The other OS(6.0,7.0,8.0,9.0) have no problem.)
Environment
OS: macOS 10.13.3
Build Logs
see the timeline 09-05 21:41:50.068 5492-5492 , 09-05 21:48:28.744 5492-5660
09-05 21:41:49.616 5492-5492/? I/zygote: Not late-enabling -Xcheck:jni (already on) 09-05 21:41:49.666 5492-5492/? W/zygote: Unexpected CPU variant for X86 using defaults: x86 09-05 21:41:49.972 5492-5492/com.example.hellowshareduijava W/monodroid: Trying to load sgen from: /data/app/com.example.hellowshareduijava-LN8btj1xE6wAY35oVDsvpw==/lib/x86/libmonosgen-2.0.so 09-05 21:41:50.055 5492-5492/com.example.hellowshareduijava W/monodroid-gc: GREF GC Threshold: 46080 09-05 21:41:50.059 5492-5492/com.example.hellowshareduijava W/monodroid: Calling into managed runtime init 09-05 21:41:50.068 5492-5492/com.example.hellowshareduijava W/lowshareduijava: type=1400 audit(0.0:11): avc: denied { read } for name="uptime" dev="proc" ino=4026532000 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:proc:s0 tclass=file permissive=0 09-05 21:48:28.744 5492-5660/com.example.hellowshareduijava D/OpenGLRenderer: HWUI GL Pipeline 09-05 21:48:28.773 5492-5660/com.example.hellowshareduijava I/zygote: android::hardware::configstore::V1_0::ISurfaceFlingerConfigs::hasWideColorDisplay retrieved: 0 09-05 21:48:28.773 5492-5660/com.example.hellowshareduijava I/OpenGLRenderer: Initialized EGL, version 1.4 09-05 21:48:28.773 5492-5660/com.example.hellowshareduijava D/OpenGLRenderer: Swap behavior 1 09-05 21:48:28.773 5492-5660/com.example.hellowshareduijava W/OpenGLRenderer: Failed to choose config with EGL_SWAP_BEHAVIOR_PRESERVED, retrying without... 09-05 21:48:28.773 5492-5660/com.example.hellowshareduijava D/OpenGLRenderer: Swap behavior 0 09-05 21:48:28.777 5492-5660/com.example.hellowshareduijava D/EGL_emulation: eglCreateContext: 0xa9b050c0: maj 2 min 0 rcv 2 09-05 21:48:28.778 5492-5660/com.example.hellowshareduijava D/EGL_emulation: eglMakeCurrent: 0xa9b050c0: ver 2 0 (tinfo 0xa9b03320) 09-05 21:48:28.824 5492-5660/com.example.hellowshareduijava D/EGL_emulation: eglMakeCurrent: 0xa9b050c0: ver 2 0 (tinfo 0xa9b03320) 09-05 21:48:28.934 5492-5503/com.example.hellowshareduijava I/zygote: Background concurrent copying GC freed 15159(3MB) AllocSpace objects, 2(40KB) LOS objects, 49% free, 2MB/4MB, paused 33us total 236.818ms
Example Project (If Possible)
We've sent the project to your email.
@rolfbjarne
I think that this issue is NOT the question, that is bug.
As you know to read my comment, I’ve tried to apply the generated aar file from the Embeddinator to our native Android application.
But it does NOT work normally, on Android OS 8.1 Device. It takes 8 minutes to entirely launch application on only Android OS 8.1 Device. (The other OS(6.0,7.0,8.0,9.0) have no problem.)
Finally, I need to release our big updated Android application on September 21, 2018. So this issue is significantly important to us. So I urgently ask you to please solve the problem as soon as possible.
Thank you.
@KimCheolYoung I've just labelled the issue so that the corresponding team can have a look at it, I personally know nothing about Android.
Have in mind that the embeddinator is currently released as a preview, which means it's not supported, and it may take a while before someone can help you.
@KimCheolYoung I think this is happening because of changes in Android 8.1. However, I have no idea why it would add 8 minutes to startup!
A quick search of avc: denied { read } for name="uptime" led to this StackOverflow question.
I think you need to implement the new logic for requesting permissions on Android Oreo: https://developer.android.com/training/permissions/requesting
Hope this helps!
I am seeing the same issue. About a 3 minute application boot up when using an Embeddinator generated AAR in our native Android application. We only see the issue on Android 8.1 (Google Pixel 2). We are developing a 3rd party API and the AAR is our deliverable. After the 3 minutes our app launched and I gave required permissions to the application. Launched the app again and still got the 3 minute boot up. It would be great to see a fix to this soon since we are planning on releasing to clients soon.
I also wanted to note that we are dealing with new permission logic for Android Oreo in our app. I placed a break point in our app and did not hit the initial app code until after the 3 minute app boot up. The code to setup permissions is not hit until after the 3 minute boot up.
I am seeing the same issue as well, where using a aar generated with Embeddinator takes a few minutes to load in a native app on Android 8.1. Even when the aar file is not being used, but is just a dependency we still see the issue.
I have discovered that when I remove the strings.xml file from the Xamarin project (in Resources/values) the app loads normally. @nisewond does this work for you?
I have no idea why this seems to fix it, but I would be curious to know.
I removed strings.xml in my Xamarin project and the issue is now resolved. Thanks so much for responding. I was afraid we were going to have to give up on Embeddinator as a solution for delivering our library to 3rd parties.