10

I'm seeing extremely slow installs of system image updates on my Android Studio 3.0 running on a macOS High Sierra system. What do I mean by "extremely slow"? Every system image update takes the better part of an hour. To my disgust, the latest set of updates (shown here from the component installer log) took over eight hours:

To install:
- Google APIs Intel x86 Atom System Image (system-images;android-24;google_apis;x86)
- Google APIs Intel x86 Atom_64 System Image (system-images;android-25;google_apis;x86_64)
- Google APIs Intel x86 Atom_64 System Image (system-images;android-23;google_apis;x86_64)
- Google APIs ARM 64 v8a System Image (system-images;android-24;google_apis;arm64-v8a)
- Google APIs Intel x86 Atom_64 System Image (system-images;android-22;google_apis;x86_64)
- Google APIs Intel x86 Atom System Image (system-images;android-23;google_apis;x86)
- Google APIs Intel x86 Atom_64 System Image (system-images;android-21;google_apis;x86_64)
- Google APIs ARM EABI v7a System Image (system-images;android-22;google_apis;armeabi-v7a)
- Google Play Intel x86 Atom System Image (system-images;android-24;google_apis_playstore;x86)
- Google APIs ARM EABI v7a System Image (system-images;android-24;google_apis;armeabi-v7a)
- Google APIs Intel x86 Atom System Image (system-images;android-26;google_apis;x86)
- Google APIs Intel x86 Atom System Image (system-images;android-22;google_apis;x86)
- Google APIs Intel x86 Atom System Image (system-images;android-21;google_apis;x86)
- Google APIs Intel x86 Atom System Image (system-images;android-19;google_apis;x86)
- Google APIs Intel x86 Atom_64 System Image (system-images;android-24;google_apis;x86_64)
- Google APIs Intel x86 Atom System Image (system-images;android-25;google_apis;x86)
- Google APIs ARM EABI v7a System Image (system-images;android-23;google_apis;armeabi-v7a)
Preparing "Install Google APIs Intel x86 Atom System Image (revision: 19)".
Downloading https://dl.google.com/android/repository/sys-img/google_apis/x86-24_r19.zip
"Install Google APIs Intel x86 Atom System Image (revision: 19)" ready.
Preparing "Install Google APIs Intel x86 Atom_64 System Image (revision: 10)".
Downloading https://dl.google.com/android/repository/sys-img/google_apis/sys-img-4252396-sdk_google_phone_x86_64-sdk_addon-4414732-sdk_google_phone_x86_64-sdk_addon-patch.jar
"Install Google APIs Intel x86 Atom_64 System Image (revision: 10)" ready.

// lots of similar lines deleted

Preparing "Install Google APIs ARM EABI v7a System Image (revision: 25)".
Downloading https://dl.google.com/android/repository/sys-img/google_apis/sys-img-4309849-sdk_google_phone_armv7-sdk_addon-4409279-sdk_google_phone_armv7-sdk_addon-patch.jar
"Install Google APIs ARM EABI v7a System Image (revision: 25)" ready.

Up to this point, everything happens fairly quickly. Then the updater starts actually updating things:

Installing Google APIs Intel x86 Atom System Image in /Users/tedhopp/Library/Android/sdk/system-images/android-24/google_apis/x86
"Install Google APIs Intel x86 Atom System Image (revision: 19)" complete.
"Install Google APIs Intel x86 Atom System Image (revision: 19)" finished.
Running patcher...
Patch applied.
Done
"Install Google APIs Intel x86 Atom_64 System Image (revision: 10)" complete.
"Install Google APIs Intel x86 Atom_64 System Image (revision: 10)" finished.
Running patcher...
Patch applied.
Done

// etc.

Each time, after the line Running patcher... appears, the update proceeds quickly through several files until it reaches "system.img". The progress bar seems to freeze there for about half an hour or more. Once that file completes, the rest of each patch proceeds very quickly.

When there are system images to update, I never have emulators or build tasks running when I start the update. For this latest update, I did have two project windows opened.

Is this slow update normal? Is there something I can do to speed it up?

Ted Hopp
  • 232,168
  • 48
  • 399
  • 521
  • I don't have any concrete reasons why this is happening, but will posit a few possibilities. `system.img` is likely a compressed filesystem image, something like `squashfs`. Compression and Decompression speed is highly dependent on cpu speeds and threads. A useful edit to your question is what cpu you have and threads available, ram and if you are using an ssd or hdd. One issue you may be seeing is if android studio is running as a single-threaded application, it could be forcing decompression and patching in a single thread which would be incredibly slow. Can you verify issue on other pcs? – NuclearPeon Nov 14 '17 at 00:41
  • @NuclearPeon - I'm running on a reasonably configured iMac development machine -- 3.1 GHz Intel Core i5 with 4 cores, 256 KB/core L2 cache, 4 MB L3 cache, 16 GB memory, and a 1 TB hard drive with plenty of free space. Android Studio is built using the IntelliJ platform which, as far as I know, doesn't have threading issues or any preference settings to control thread use. System image updates are also slow on a Windows machine. Other updates (SDK tools, etc.) install quite quickly. – Ted Hopp Nov 14 '17 at 03:14
  • `1/2` I'll continue doing some investigating, but in the meantime... have you tried increasing your java vm heap size? https://stackoverflow.com/questions/17221725/how-to-increase-the-memory-heap-size-on-intellij-idea. I'm assuming your android studio is 64-bit. Do you have any updates to java on your mac? Are you using Android Studio's stable update channel? (`Tools/Android/SDK Manager`, then click `Updates` in the same sidebar level list). What exact version of AS specifically do you have? Another thing to consider: do you have file indexing on the folder with all those `system.img` files? – NuclearPeon Nov 14 '17 at 22:38
  • `2/2` Is the Android Image running while the update is occuring? I have tried to replicate the issue by installing AS 3, Build `#AI-171.4408382` with Java OpenJDK 8 (`1.8.0_144-b01`) on 64-bit Gentoo Linux+KDE. I have a 2nd gen i7 2640M @ 2.80Ghz, dual core/4 threads, 16GB RAM and Samsung PRO 850 SSD. At this point I think the slowness is either an indexing issue or the lack of an SSD. I will test on my Windows 7 Laptop later and let you know the results. Sorry, there's not much more I can do. (I downloaded / installed various NDK/SDKs/VDKs in about 40 minutes: 4.4/5/6/7/8, nexus img, updates) – NuclearPeon Nov 14 '17 at 22:38
  • I have a few more thoughts. I have a macbook air (with ssd) that I installed AS 3 on. When it came to downloading a virtual machine, things took longer that I had anticipated: What does your network traffic look like? Wireless/wired? Downloading updates over wireless for ~2GB files might be part of the problem. Using High Sierra, you are maybe on the new APFS filesystem. Since it's a new fs, there may be kinks to work out. Possibly your hard drive is failing, esp. if you are using the original drive. I think your mac is late 2011, that's ~6 years of use. Tho it wouldnt explain windows slowness – NuclearPeon Nov 15 '17 at 00:08
  • If you completely disable spotlight (in System Preferences) or file indexer in windows, do you notice any speedup? Try copying a large file from a dvd if that is an option, or burn a system image or two file to dvd and then try copying it back to your hard drive to emulate a slow wireless connection download. Does it still take an hour? – NuclearPeon Nov 15 '17 at 00:13
  • @NuclearPeon - 2011? No. My Mac is a Retina 4K, late 2015 model. I'm not having any other performance problems that would indicate a hard drive issue. I'm running the latest stable AS release that you are (build AI-171.4408382). I was running Sun's Java 8 (1.8.0_151). I just upgraded to JDK 9 (build 9.0.1+11). I'll wait to see what happens with the next AS update, but I'm not expecting any big improvements. Regarding network speed--that can't be the issue because all downloads finish before the AS component installer starts patching files. It's the latter step that takes so long. – Ted Hopp Nov 15 '17 at 02:47
  • I'm really sorry I don't have much else to offer you with this issue. I looked up your mac model based on cpu speeds and 2011 came up, hence my assumption... I do have one last possible avenue: you can look through the android studio logs for errors or timestamps that indicate long operations. There's also the ability to set `Debug Log Settings` and view the log folder in the `Help` menu. Lastly, you might want to file a ticket against android studio. I agree that there is something wrong with those images taking 8+ hours to update when they are downloaded locally. Best of luck. – NuclearPeon Nov 15 '17 at 23:34
  • I have similar issue here. I am running ubuntu 16.04 on a quad-core with 2 threads per core and 8 Gb of memory. It is taking forever and other applications are freezing during that time. I en up canceling the process twice and gave up. – innoSPG Dec 27 '17 at 18:03
  • 1
    I finally got around by uninstalling the images (that were being updated) and reinstall those images from scratch, it was way faster. I will see what happens at the next update. – innoSPG Dec 28 '17 at 20:39
  • @innoSPG - Well, that's encouraging! If the next update goes quickly, write up your finding as an answer and I'll accept it. Meanwhile, I'm going to try the same thing. – Ted Hopp Dec 28 '17 at 21:49
  • 2
    @innoSPG - Thank you for the information. I have a similar setup (16.04/dual core/8Gb) and it's taken forever. Next time I shall also uninstall and reinstall from scratch. - and they have the gall to entitle the installer box "SDK Quickfix Installation" – NickT Mar 29 '18 at 10:43
  • Similar problems on my Windows laptop (i5-5200U @ 2.2GHz, 8GB RAM). CPU is 14%, Memory 53%, Disk 99%, with nearly all disk i/o from AndroidStudio patching userdata.img. – phatfingers Apr 10 '18 at 15:48
  • Despite my previously stated intention, I forgot to delete then install from scratch, so the update again took ages. After this I deliberately removed an image, then put it back, for a test. It was SO MUCH QUICKER than the patch process. It was performance issues like this that forced the removal of Eclipse as the preferred IDE in favour of Android Studio - I wonder what the next official IDE will be, when the developers decide to screw up the paper, chuck it in the bin and start again with a clean sheet? – NickT Apr 29 '18 at 11:14
  • 1
    This happens to me too.... I don't have a slow PC, it's an i7 with 16 GB ram. It's not SSD disk tough... *Running patcher* takes forever.... – Daniele Segato May 07 '18 at 09:43

1 Answers1

4

I've the same issue.

As you said, deleting the current SDK version and reinstalling it from scratch is faster (only download time is the variable here).

I've looked for an issue for this and since I didn't find one I decided to create it here: https://issuetracker.google.com/issues/79307669

feel free to star it.

I doubt this is related to the version of Android Studio so I invite you to write in comment of that issue some information on your system:

  • Android Studio version,
  • Java version,
  • OS,
  • CPU,
  • RAM (and how much of it used for Android Studio JVM),
  • Type of Disk Storage (Magnetic / Solid drive)
  • Filesystem

in the hope we find some common variable that can cause the issue.

This is mine: AS 3.2 Canary 13, OS Linux (Ubuntu 64 bit 16.04 LTS), CPU: Intel i7, RAM 16 GB (-Xmx4g), Storage Magnetic Drive (not solid), Filesystem: Ext4

Daniele Segato
  • 12,314
  • 6
  • 62
  • 88
  • 2
    Thought I'd mention that the issue is closed-fixed now: _In SDK manager, on "SDK Update Sites" tab, there is now a new option called "Disable SDK diff pacthing"._ – Roflo May 08 '19 at 18:29