3

We are experiencing extremely long installation/start/run times for Android Things applications on the NXP PICO-PI-IMX6UL. This issue is observable when using both Android Studio and adb directly on the command line.

A small application of ~2MB in size takes anywhere from 5 to 15 minutes to install. The same application on the Intel Edison only takes only a few seconds to install.

It's worth noting that other adb operations seem to run very slowly as well (i.e. shell, logcat, etc.).

We have closely followed the procedures outlined using these resources to install the Android Things image: https://developer.android.com/things/hardware/imx6ul.html

We have re-flashed the Android Things image several times and experience the same issues.

To rule out any application issues, we have tried installing/running the Android Things sample template application found here: https://github.com/androidthings/new-project-template and experience the same issues. We can verify that this application installs/runs without issue on an Intel Edison board running Android Things 4.1.

Here are a few more details about our setup:

Host:

  • Mac OS 10.12.6
  • Android Studio version 2.3.3
  • Android Debug Bridge version 1.0.39

i.MX6UL:

  • Android Things Developer Preview Image 5.1

Any suggestions on what is wrong with our setup or what might be causing these issues?

Thanks!

Update 10/20/2017

Further testing with additional NXP i.MX6UL boards has only shown minor improvements in installation and runtimes, and the results are not consistent. We also tried swapping out the daughterboard for an older version (Wandboard i.MX6UL), but the results were the same.

We plan to continue testing as newer versions of Android Things are released, but in the meantime we are going to continue development with the Intel Edison, despite it being discontinued.

ryanecrist
  • 328
  • 2
  • 9
  • Isn't the Intel Edison ADB over USB and NXPi.MX ADB over WiFi? (i.e. the problem might be your router wifi settings) – Blundell Sep 20 '17 at 15:17
  • Thanks for the comment, @Blundell. Actually we have observed this behavior using both USB and WiFi (the NXP i.MX6UL supports both). – ryanecrist Sep 20 '17 at 17:46
  • another suggestion is to try Android Studio 3.0 but then that shouldn't affect the ADB version, unless you also try the preview tools. I don't have a i.MX6UL is it power over USBC? As i have heard that the usb-c port on the new mac laptops isn't powerful enough and you should use a powered hub – Blundell Sep 20 '17 at 18:29
  • The same problem occurs using Android Studio 3.0. The i.MX6UL does use USB-C; however, the problem also occurs when powering the board using a 5W wall brick and running adb over Wifi. – ryanecrist Sep 20 '17 at 19:36
  • Does that board use an SD card? This user solved a similar problem by swapping it out for a new one: https://stackoverflow.com/a/45846592/2202359 – j2abro Sep 22 '17 at 00:20
  • Thanks @j2abro, unfortunately the i.MX6UL uses internal flash storage. – ryanecrist Sep 22 '17 at 12:49
  • Did you find any solution? I do have the same problem too... – Efthymios Kalyviotis Oct 14 '17 at 16:12
  • @ekalyvio Unfortunately we have not found a solution yet. Please see my update above for more details. – ryanecrist Oct 20 '17 at 13:38
  • @ryanecrist Can you check it with Android Studio 3.0 RC1? It seems to me slightly faster than 2.1. I also observed the following. Usually, the app installation to the device is quite fast and the app starts running automatically but the IDE continues thinking that the app is being installed although it has finished installing and is running (I can see the logcat of my app). That is why it takes ages. Could it be easy for you to verify it? – Efthymios Kalyviotis Oct 21 '17 at 12:18
  • 1
    @ekalyvio Sorry for my delayed response. Just tested on Android Studio 3.0 (released 2 days ago) and unfortunately the problem still exists. Observing logcat I can see that the `dex2oat` process taking much longer than the installing the same build on the Edison board. – ryanecrist Oct 27 '17 at 17:09

1 Answers1

0

I assume there is something wrong with the chip configuration, since simply keeping the kernel "alive" keeps the system rather busy with only 50% idle.. Running the gradle task "uninstallAll" solved the problem if I was not able to start further debug sessions.

Show current CPU usage:

adb shell

top

All running processes shown with top

Community
  • 1
  • 1
Michael Guntli
  • 56
  • 4