Moving apps from the Android phone memory to SD card: HTC Desire

So I’ve had my HTC Desire now for approximately 2 years now and whilst it has served me well I’ve had a bug bear with it for a long time. Essentially the phone has only 148 MB of internal storage and after the basic Android OS has been installed this is reduced to under 134 MB. Now I knew that this phone didn’t have much memory when I bought it, and as a result when I bought the phone I bought it with a 16 GB microSD card.

However, there are a lot of apps that don’t like to play if they’re installed to the SD card. And it doesn’t take too many apps such as Google+ (at over 20 MB) and suddenly you cant update any apps through a lack of phone space due to apps being downloaded to phone memory before being moved.

Eventually I’ve got completely sick of this and as I have my phone rooted and running Cyanogenmod I thought I’d use some basic Linux file system trickery to move all apps to the SD card but set some symbolic links in the link file system so that the apps still think they’re on phone memory.

So, here’s what I’ve done. This isn’t for the faint of heart and if you’re worried either don’t bother or backup your phone first. All apps you can redownload for free from the Android Market in any case, but I’m not going to take responsibility for your actions.

So open the Terminal Emulator program, and then give it super user permissions so we can access and change core Android.

1
su

A message prompt should appear saying that the Terminal Emulator has been given super user permissions, if you havent done it before then you need to Allow access. Remember that Android (and linux) is case sensitive

1
cp -rv /data/data /sdcard/Android

The -rv flag means; r to copy recursively (ie every folder), and v to show us in the terminal every file that is copied. We could copy to any folder on the SD card but I’ve stuck it into the folder where apps are stored when you send them to the SD card anyway.

With the files copied across we can now remove the old ones (we could have used the mv command but I was prefer a copy and remove, it’s a bit safer)

1
rm -r /data/data

Then we need to link the new location back to the old with a symbolic link

1
ln -s /sdcard/Android/data /data/data

Sorted! This should have now cleared up an awful lot of space. But if space is still an issue we can move the Dalvik cache. The Dalvik cache is the cache for Dalvik, which doesnt help much unless you know that Dalvik is the Java virtual machine for Android, so the Dalvik cache is basically the space where all the program information gets dumped whilst it’s running.

To do this is pretty simple too, following the above:

1
2
3
cp -r /data/dalvik-cache /sdcard/Android
rm -r /data/dalvik-cache
ln -s /sdcard/Android/dalvik-cache /data/dalvik-cache

Obviously, the problem with this is that you can now, never remove your SD card without having to move these back to the phone.

Also note that your apps will take a second or two to start the first time after the move as it rebuilds the cache.

Update: After doing a restart (as the battery ran flat), I ran into a huge number of problems with apps not responding; most annoying the keyboard restarting every 10 seconds.

Poking around online I came across a few things. For those not wanting to risk experimental builds then there is a fantastic resource here for managing your apps onto SD. However, newer builds of Android, namely those with an ICS flare have automated memory management by partitioning off part of the SD card to apps so that the root system seems the partition as part of phone memory.

So with a quick flash to Ice Cream Sandwich using a Cyanogenmod 9 beta and everything is hunky-dorey


This page previously appeared on morganbye.net[^1][^2][^3]

[^1:] http://morganbye.net/moving-apps-from-the-android-phone-memory-to-sd-card-htc-desire [^2:] http://morganbye.net/2012/03/moving-apps-from-the-android-phone-memory-to-sd-card-htc-desire) [^3:] http://morganbye.net/uncategorized/2012/03/moving-apps-from-the-android-phone-memory-to-sd-card-htc-desire/

HTC Desire headphone jack fix

This morning on the way to work I got down to the road, plugged in my earphones to my phone and hit play on Spotify. Only for some horrible, tinny, quiet music to come out. It seemed that the phone just simply would not recognise that anything had …

How do you define successful engineering leadership?

The Philosophy

Many view technical leadership as being the “smartest architect in the room.” I see it as the opposite. My job is to build a room where I don’t have to be the smartest person because the systems, culture, and communication are so robust that the team can out-innovate me.

The Strategy

  • Alignment: Does every engineer understand how their sprint task impacts the company’s bottom line?
  • Velocity vs. Stability: We aren’t just “shipping fast”; we are building a predictable, repeatable engine that doesn’t collapse under its own weight at the next order of magnitude.
  • The Human Growth Curve: Success is when the engineering team’s capability evolves faster than the product’s complexity. If the team feels stagnant, the tech stack will soon follow.

What is your approach to scaling technical organizations?

The Philosophy

Scaling isn’t just “hiring more people” - that’s often how you slow down. Scaling is about moving from Individual Heroics to Organizational Systems.

The Strategy

  • The 3-Continent Perspective: Having managed global teams, I focus on “High-Signal Communication.” As you grow, the cost of a meeting triples. I implement “Asynchronous-First” cultures that protect deep-work time while ensuring no one is blocked by a timezone.

  • Modular Autonomy: I advocate for breaking down monolithic teams into autonomous units with clear ownership. This reduces the “communication tax” and allows us to scale the headcount without scaling the bureaucracy.

  • Automation as Infrastructure: At petabyte scale, manual intervention is a failure. I treat the developer experience (CI/CD, observability, self-service infra) as a first-class product to keep the “path to production” frictionless.

How do you balance high-growth velocity with technical stability?

The Philosophy

Technical debt isn’t a “bad thing” to be avoided; it’s a set of historical decisions that no longer serve you. Like any loan, leverage can accelerate growth when investments payoff. But if velocity and returns are slowing you need a payment plan before the interest kills you.

The Strategy

  • The ROI Filter: I don’t refactor for the sake of “clean code.” I don’t refactor a micro-service with no users. I refactor when the pain on that debt - measured in bugs, downtime, or developer frustration - starts to exceed the cost of the fix.

  • Zero-Downtime Culture: Especially at scale, stability is a feature. I implement “Guardrail Engineering” where the system is designed to fail gracefully, ensuring that a Series B growth spike becomes a success story rather than a post-mortem.

  • The 70/20/10 Rule: I typically aim to dedicate 70% of resources to new features, 20% to infrastructure/debt, and 10% to R&D. This ensures we never stop innovating, but we never stop fortifying either.