[TIMOB-9859] Android: increase AVD storage size to reduce [FAILED_INSUFFICIENT_STORAGE] errors
| GitHub Issue | n/a |
|---|
| Type | New Feature |
|---|
| Priority | High |
|---|
| Status | Closed |
|---|
| Resolution | Won't Fix |
|---|
| Resolution Date | 2013-10-17T08:37:44.000+0000 |
|---|
| Affected Version/s | Release 2.1.0 |
|---|
| Fix Version/s | n/a |
|---|
| Components | CLI, Tooling |
|---|
| Labels | androidbuild, ay-verified, cb-verified, core, insight |
|---|
| Reporter | Tim Poulsen |
|---|
| Assignee | Chris Barber |
|---|
| Created | 2012-07-02T12:19:20.000+0000 |
|---|
| Updated | 2017-03-22T17:50:01.000+0000 |
|---|
Description
Expected results:
I should be able to build and install more than a few Ti apps to an Android emulator.
Actual results:
Due to defaults defined in builder.py, I can fit only a couple of Ti apps before the emulator runs out of storage space. This results in a [FAILED_INSUFFICIENT_STORAGE] error. I can delete other apps to free space. However, if I need to work on multiple apps, I end up having to delete/install frequently.
Fix
In builder.py (in my version, line 491) increase the partition size value. Current value is 128 (MB). I suggest at least 1024.
Comments
JSON Source
We should expose a configurable parameter.
We should take care of this in the new CLI.
We have decided to NOT increase the size of the AVD, but rather improve installation errors when there's insufficient space (TIMOB-14701).
Gaahhh! Curse you Perry the Platypus!
[~cbarber] Wait...what about the idea of adding a configurable parameter? That would be very important for Studio users who could choose a new default.
Yes! Thank you Ingo! When I'm using the emulator, I just want to be able to install all/any of my apps, and keep their data intact.
if we aren't going to make it configurable, at least document your build scripts so we know where to start hacking again. Have hacked build scripts for 3+ years to build a decent sized AVD or sdcard image to work with.
[~skypanther] Would you suggest those be command-line flags, or just changes in how we create the defaults? Also, do you think that 1024 MB really is the bare minimum now?
From private comment, orientation/accelerometer and keyboard emulation should be enabled by default. As for AVD size, average development-version APK size is running around 50 MB these days. So, 10 apps would be ~512MB. I'd say that's the bare minimum. Perhaps the better way to handle this is to: - Create a basic AVD using the defaults I listed - Add a command-line flag (expose in Studio UI too) that lets the developer target a specific AVD that he/she has created manually. The Android tooling lets you create AVDs that emulate specific devices or include various hardware emulations.
Tim's math is based upon 10 unique apps pushed x number of times to the emulator. ADB doesn't always clean up after itself on an install (sometimes at all/sometimes slowly). If the original apk is locked myapp(1).apk then when the update is pushed myapp(2).apk the first one may not be deleted. This occurs less often with newer android tooling and new titanium tooling. However, you could have a single app, built multiple times, fill a 64-512mb with as few as 1-10 failed pushes. (and lord knows with the android emulator, there aren't enough chickens or pentagrams to keep those failures at bay) I won't even bring up the 50+mb debugging logs that adb can accumulate without cleaning up after itself.
[~sfeather] We were curious--what hacking did you do on the build scripts?
In case Stephen doesn't respond, I used to do the same thing: edit the AVD definition command in the python script. I had to re-apply the fix with each new release of the SDK. But it was worth the trouble. Following up on Stephen's comment about ADB not cleaning itself up: I'm debugging interapp communication on Android, which requires two apps. I can install both once. But any subsequent builds for the second app give me the insufficient space error -- buried within a ton of other Android console output. It's easy to miss the fact that you're not really running the new version which didn't get installed because there wasn't space. I have to delete the second app after each test run, then build the new version. ADB not cleaning up is obviously not our problem. But, a larger AVD size and better error messaging, would lessen the impact of ADB's failings.
One discussion we had was that by upping the size of every AVD, that could consume significant additional space. An alternate approach was for us to reuse the existing AVDs that come with the Android SDK rather than creating new ones ourselves. Thoughts?
[~skypanther] And you're editing approximately line https://github.com/appcelerator/titanium_mobile/blob/eb183c0991900c73c01513c0c4861c9498519ecf/support/android/builder.py#L603?
> One discussion we had was that by upping the size of every AVD, > that could consume significant additional space. "Additional space" where? On my hard drive? I've got hundreds of GB free.
[~bitshiftr] You do, but not everyone does, and I don't like making the assumption that I could grab an extra 10 GB off someone's SSD. That's why I'd prefer to it be a preference of some kind over a stock value.
Ingo, yes, line 603 that you referenced. Reusing existing AVDs would be great. Keep in mind that none are created by default with a new install. Still, having the option to use one I define myself would be wonderful. It could be a build option.
Agreed about the additional HD/SSD space. I'm still a fan of the idea of making it a Ti Studio preference. Then if I want to up the size of every AVD, I can do it.
In Titanium SDK 3.2.0, we no longer create AVDs. You must create your own AVDs. This way you can reuse emulators, configure them as you see fit, and avoid creating a dozen "titanium_*" AVDs. As apart of TIMOB-14701, we now display a helpful error message when there's insufficient space.
Closing ticket as the issue will not fix and with reference to the above comments.