My Phone Was Slow. Here's How I Made It Faster
My phone had started to feel sluggish. Apps reloaded when I switched between them, scrolling sometimes dragged, and storage was nearly full. I didn't want to install a "booster" app or start disabling things at random. So I connected the phone to my Mac with adb and tried to understand what was actually going on.
The phone was a Samsung Galaxy S23 Ultra with 8 GB of RAM. After the audit, storage use went from 88% to 74%, installed apps from 289 to 185, and load average from 16 to under 3. That sounds like a big improvement, and it was. But it's one phone, not a promise that the same changes will work for yours.
The most useful thing wasn't a magic setting. It was taking measurements before making changes, doing one thing at a time, and keeping a way to undo it.
What I used
- Samsung Galaxy S23 Ultra, One UI 9 / Android 17
- MacBook running macOS Sequoia
- Android Platform-Tools 37.0.1
- A USB cable that carries data
- A Claude model in the Pi agent harness, running in Herdr inside Ghostty
I tested the commands only in this setup. Other Android versions, manufacturers, computers, and AI assistants are untested. Samsung menu names and com.samsung... package names are specific to Samsung; they won't map neatly to every Android phone.
You don't need an AI assistant to follow this. It can run the commands and help explain the output, but you can also run them yourself. I used the assistant to help with the audit and told it not to change anything unless I approved the change first.
What adb can and can't do
adb (Android Debug Bridge) is Google's tool for letting a computer inspect and control a connected Android phone. It can show resource use, list apps, restrict background activity, disable some preinstalled apps, clear caches, and change animation scales.
There are limits. Without root, you can disable some system apps, but you can't remove them. adb can't change Samsung RAM Plus, set the wallpaper, inspect Secure Folder or other user profiles, or read Samsung Modes and Routines. And no setting can make a phone's hardware do more than it can. If 8 GB of RAM isn't enough for the apps you use, the answer may be fewer apps—or a phone with more RAM.
Start with what you notice
Different symptoms can have different causes. I wouldn't start by applying every tweak in the guide. Tell your AI agent what is the stuff that is bugging you. In my case it was slow to open new apps and the startup also was super slow.
| What you notice | Where to look | What you might try |
|---|---|---|
| Apps reload when you switch; scrolling stutters | Memory, swap, and kswapd0 |
Restart, review RAM Plus, check background apps |
| It gets slow after a few days, then improves after restart | Uptime | Check the restart settings |
| Storage is nearly full | /data and app storage |
Review caches, photos, downloads, and apps |
| The phone is hot or battery drains quickly | Busy processes and background activity | Find which app is actually doing the work |
| It's slow soon after a restart | Background apps, exemptions, and duplicate tools | Review apps and background limits |
| Numbers look normal, but it still feels slow | Wallpaper and transitions | Review Samsung extras and animations |
Before you connect the phone
A few things are worth thinking about before enabling USB debugging.
The output can be personal. It may show your app list (including banking, health, or work apps), usage history, device identifiers, and file names. Check what your AI tool sends and stores. If you share output publicly, remove serial numbers, account names, or package names you don't want others to see.
A computer you authorize can control the phone. Only authorize a computer you trust. When you're finished, turn off USB debugging and use Developer options → Revoke USB debugging authorizations.
Get adb from Google or use a trusted package manager such as Homebrew. You don't need any "phone cleaner" apps for this. I also wouldn't let an assistant enter passwords, 2-factor codes, or recovery codes. Ask it to explain every command that changes the phone before it runs the command.
1. Set up adb
On a Mac with Homebrew:
brew install --cask android-platform-tools
Google has downloads for other systems at developer.android.com/tools/releases/platform-tools. I haven't tested those setups. Check that adb is installed:
adb version
To connect the phone:
- Go to Settings → About phone → Software information and tap Build number seven times. This enables Developer options.
- Open Settings → Developer options and turn on USB debugging.
- Connect the phone and choose File transfer as the USB mode. On my Samsung, the permission prompt didn't appear in "Charging only" mode.
- Unlock the phone and tap Allow on "Allow USB debugging?" Only tick "Always allow from this computer" if you trust that computer.
- Run
adb devices. The status should saydevice.
If it says unauthorized, unlock and reconnect, or revoke USB debugging authorizations and try again. On my Samsung, I also had to turn off Auto Blocker under Settings → Security and privacy while I worked.
If you're working with an AI assistant
I opened the assistant in a scratch folder and started with a read-only request, something like:
My Android phone is connected with adb. Run a read-only performance audit: memory, swap, storage, busiest processes, apps I haven't used in 90 days, and apps allowed to run in the background. Don't change anything. Summarize what you find and propose changes. Wait for my approval before running any command that changes the phone.
That last part matters. The assistant can inspect and suggest, but I approve each change. I also asked it to keep a log and make a rollback script. You can do the same audit without an assistant.
2. Take a baseline
I wrote down the numbers before changing anything.
Memory, storage, uptime, and battery
These commands are for inspecting the things that make the most impact on phone's speed:
adb shell uptime
adb shell cat /proc/meminfo | grep -E 'MemAvailable|SwapTotal|SwapFree'
adb shell top -b -n 1 -m 15 -s 9
adb shell df -h /data
adb shell dumpsys battery | grep -E 'level|temperature|health'
I also counted the third-party apps:
adb shell pm list packages -3 | wc -l
Record storage use, MemAvailable, swap in use, load average, uptime, and the app count. These readings are easier to interpret together:
- On an 8 GB phone,
MemAvailablebelow about 2 GB along with significant swap use can point to memory pressure. - A busy
kswapd0intopsupports that explanation. - A load average well above the core count (8 on most phones) suggests the phone is working hard.
- Battery temperature is in tenths of a degree Celsius:
338means 33.8 °C. Sustained readings above about 42 °C are a concern. - Storage use above about 80% means
/datais getting crowded. It's a rule of thumb, not a hard cutoff.
None of these numbers tells the whole story by itself.
Look at processes and app storage
adb shell dumpsys meminfo | sed -n '/Total PSS by process/,/Total PSS by OOM/p' | head -40
adb shell dumpsys alarm | sed -n '/Top Alarms:/,/^$/p'
adb shell pm list packages -3
adb shell dumpsys diskstats
Look for processes using hundreds of MB, apps holding gigabytes of data or cache, and processes marked (user 150). On my phone, those processes belonged to Secure Folder. Streaming, social, and video apps can use a surprising amount of storage.
Check battery exemptions and standby buckets
adb shell dumpsys deviceidle whitelist | grep '^user'
adb shell am get-standby-bucket
Standby bucket values: 5 exempt, 10 active, 20 working, 30 frequent, 40 rare, 45 restricted, 50 never. I kept the exemption list short. An exempt app can run more freely in the background, so it's worth knowing why each app is there.
A note about kswapd0
kswapd0 is a thread in Android's Linux kernel. It helps keep memory available by reclaiming data that can be loaded again and moving or compressing other data into swap, an area on storage. Some activity is normal.
The problem is when the phone is constantly short on RAM. Then kswapd0 can run all the time, and apps stall as data is moved back from storage. That's called thrashing. In my audit, kswapd0 had used about 5½ hours of CPU time in ten days. If it's near the top of top even after a restart, memory pressure may be part of the problem. Check the other readings too.
Why leave some storage free?
"Keep storage under 80%" is a rule of thumb, not a magic number. Flash storage needs free blocks for writes, and apps need room for caches, temporary files, databases, and updates. Samsung RAM Plus also uses storage as virtual memory. It doesn't work like adding physical RAM.
3. Make changes carefully
Before changing settings, I backed up anything I couldn't replace and checked that the backup could be restored. The 3-2-1 rule is a useful reminder: three copies, on two kinds of storage, with one copy offsite. Photos only on the phone—or only in Google Photos—are one copy and one point of failure. I backed up before this audit.
I also wrote down the current state, logged changes, and kept a rollback script. I preferred reversible changes: disabling an app with pm disable-user is easier to undo than uninstalling it, which can lose app data. I changed one small group of things at a time and used the phone for a day before continuing.
I didn't let the assistant delete or uninstall anything without showing me the list first. Before touching banking or authenticator apps, I made sure I had recovery codes and knew how I'd sign in again.
There's a point where it's better to stop. Over-tuning can mean missed notifications, broken features, and a lot of time spent figuring out what went wrong. If you're unsure what an app does, leave it alone. The goal is a phone that works well for you, not a perfect-looking audit.
4. Changes to consider
Restart the phone and check automatic restarts
I restarted the phone first. On Samsung, look under Settings → Battery and device care → Auto optimization → Restart when needed.
On my phone, "Restart when needed" was already on, but it still hadn't restarted automatically for months. I also had a scheduled restart enabled. The two settings seemed to clash. I left only one restart method on and checked uptime with adb shell uptime afterward.
Adjust Samsung RAM Plus
Samsung RAM Plus uses storage as virtual memory. Change it in Settings → Battery and device care → Memory → RAM Plus; adb can't change it. Restart after changing the setting.
| Setting | What to expect |
|---|---|
| 8 GB (my original setting) | More apps may stay open, but there can be more swapping and lag when memory is under pressure. |
| 4 GB (what I chose) | Fewer apps stay open; some reload, but swapping was lower. |
| Off | Least virtual memory, but more apps reload. Browser tabs and games may restart. |
This is a tradeoff: keeping more apps open versus reducing storage-based swapping. I tried 4 GB for a week. If the apps you rely on keep reloading, try 6 GB. I wouldn't treat my setting as a universal recommendation.
Restrict background apps without losing alerts
Android has a few different controls, and they don't all do the same thing:
| Control | What it does |
|---|---|
| Battery optimization exemption ("Unrestricted") | Lets an app run more freely in the background |
| Background restriction ("Deep sleeping" on Samsung) | Stops the app after you leave it; notifications may stop too |
| Standby bucket | Limits how often the app's jobs and alarms can run |
I'd usually leave messaging, work chat, email, banking and payment approvals, authenticator apps, ride and delivery apps, location sharing, VPN, and sync apps unrestricted. Shopping, travel, games, media players, AI chatbots, and utilities may be candidates for restrictions if they don't need to do anything in the background.
For a package you've identified and reviewed, these commands restrict its background activity, set its standby bucket, and remove its battery exemption:
adb shell cmd appops set <package> RUN_ANY_IN_BACKGROUND ignore
adb shell am set-standby-bucket <package> restricted
adb shell cmd deviceidle whitelist -<package>
To undo the app-ops and standby changes:
adb shell cmd appops set <package> RUN_ANY_IN_BACKGROUND allow
adb shell am set-standby-bucket <package> active
On Samsung, also check Settings → Battery → Background usage limits → Deep sleeping apps. Opening an app doesn't necessarily remove it from that list. "Put unused apps to sleep" may deep-sleep apps that haven't been used for about 30 days. I nearly deep-slept a ride-hailing app I still needed for trip updates. An app can be important even if you rarely open it.
Clear caches when there's a reason
A cache is data an app saves so it doesn't have to fetch or create it again: thumbnails, images, web pages, map tiles. Clearing a cache normally doesn't remove logins, messages, or personal files, but the app may be slower the next time and may download that data again.
adb shell pm trim-caches 999G
I'd clear caches if storage is tight, a few apps have accumulated gigabytes, or an app is misbehaving. This phone had about 10 GB of cache in total, mostly from browser, video, and social apps.
If storage is healthy, clearing caches on a schedule doesn't help much. Caches refill, and the next download uses data. I'd also hold off before travel if an app's cached content matters offline. Streaming downloads and offline maps are usually app data, not cache; delete those from inside the app.
Move photos and videos without losing the backup
Moving photos and videos off the phone can free a lot of space. I used self-hosted Immich; Google Photos or a NAS are other options. Whatever you use, confirm the upload finished before deleting local copies. Keep another copy on different storage and one offsite, following the 3-2-1 rule.
There's one thing to watch for: if Syncthing, FolderSync, or another sync app mirrors the camera folder, deleting a photo on the phone may delete the synced copy too. Use the backup app's "free up space" option or configure the destination to ignore deletions. Offline streaming downloads can also use several GB, so remove those inside their apps.
Review apps you no longer use
Android usage history can show when apps were last opened. On my phone it went back about eight months:
adb shell dumpsys usagestats
An old lastTimeUsed date—or 1970-01-01—means there was no recent use recorded for that app. It doesn't tell you whether the app is quietly syncing, backing up, automating, or providing VPN/security functions. Samsung's Settings → Battery → Background usage limits also lists apps it considers unused.
An assistant can combine app names, usage dates, and sizes into a table. I still reviewed every item myself. Banking apps may be needed to approve payments. Authenticator apps hold your codes. Government or certificate apps can be hard to reissue. A work VPN or security app may be required by your employer. "I haven't opened it lately" isn't enough to know it's safe to remove.
I removed apps I wasn't using, especially games, duplicates, and one-off shopping, delivery, or travel apps I could access on the web. Before uninstalling anything, check what it does, save any data you need, and make sure you can sign in again.
adb shell pm uninstall <package>
Disable selected Samsung apps
Without root, Android 17 wouldn't let me remove system apps, but I could disable some of them. This can vary by device and software version, so look up each package and its dependencies before changing anything.
adb shell pm disable-user --user 0 <package>
adb shell pm enable <package> # undo
On my phone, I disabled Bixby (assistant and voice wake-up), Game Launcher, Link to Windows, Facebook's preinstalled helper services, and Samsung Notes, which I didn't use.
I left these enabled:
- Bixby language packs and Samsung speech and translation packs; they support Voice Recorder transcription and translation.
- Game Booster and Game Optimizing Service; they run when a game is open.
- Bixby Vision framework; the camera or gallery may use it.
- Samsung Keyboard. Android turned it back on within seconds, and it supports S Pen handwriting-to-text.
- Samsung Cloud and Samsung account. I turned off sync in Settings → Accounts and backup instead of disabling the app.
- Smart suggestions, which also powers app-drawer search.
- Google Play Services and other Google system apps, which many apps depend on.
- Facebook Messenger, because I still needed its messages after removing the Facebook app.
I disabled one package, kept a rollback list, and used the phone for a day before making another change.
Look for duplicate tools
A duplicate app isn't automatically a problem, but it may mean another background service. These were the overlaps I found:
- Autosync, FolderSync, and Syncthing: I kept Autosync for a notes vault and planned to move that job to Syncthing.
- MacroDroid and Samsung Modes and Routines: I kept Routines because it was lighter and flagged MacroDroid for review.
- SwiftKey and Samsung Keyboard: SwiftKey was my default, but Samsung Keyboard still stayed in memory.
- Google Photos, Samsung Cloud, and Immich: I chose one main photo-backup route while keeping separate backup copies.
- Two work chat apps: an old one stayed installed after a workplace change. I removed it after confirming the replacement.
Review Samsung features you don't use
These are things I checked on this phone, not a checklist everyone should follow:
- Live wallpaper: used about 225 MB of RAM. A still image set through Samsung's wallpaper service could still use around 180 MB; depth and motion effects may add to that.
- Smart suggestions: background learning and daily wake-ups; a second copy ran inside Secure Folder.
- Bixby voice wake-up and related services, if you don't use them.
- S Pen Air actions: I could turn off pen-button gestures while keeping writing, Air command, and screen-off memos.
- Samsung Cloud sync and backup: turn sync off in Accounts and backup; don't disable the app.
- Secure Folder: it ran 17 processes and used about 370 MB. If you remove it, move its files out first; they'll be deleted with it.
Shorten animations
After dealing with memory pressure, I changed Window animation scale, Transition animation scale, and Animator duration scale to 0.5× in Developer options:
adb shell settings put global window_animation_scale 0.5
adb shell settings put global transition_animation_scale 0.5
adb shell settings put global animator_duration_scale 0.5
If the next screen isn't ready, the shorter animation can make the wait more noticeable. I found 0.5× a reasonable middle ground.
This is one of the things that made my device feel much faster, even if it doesn't make the phone load or render things faster. It just shortens transitions.
5. Compare the results
Here's what changed on my phone:
| Measure | Before | After |
|---|---|---|
| Storage used | 88% | 74% |
| Installed apps | 289 | 185 |
| Load average | 16 | Under 3 |
| Swap in use four minutes after reboot | 2.6 GB | Lower, with RAM Plus at 4 GB |
| Android user profiles running | 2 | 1 |
But what I noticed it the most is when I started using it. It's crazy fast now.
6. Keep checking in
I'd repeat the audit every three months. A calendar reminder is enough:
- Check storage; aim for below about 80%. Clear caches only if it helps.
- Check memory pressure and
kswapd0. - Review apps you haven't used in 90 days, and check what they do before uninstalling.
- Review battery exemptions and background limits.
- Check whether an update changed any settings.
- Check uptime. If it hasn't restarted automatically in two weeks, revisit the restart setting.
- Restart the phone.
- Turn off USB debugging and revoke authorizations.
If an 8 GB phone still feels tight after that, more aggressive restrictions may not be the answer. Fewer apps—or more RAM—might be what you need.
Appendix A: Rollback script template
I asked the assistant for a rollback script that matched the changes I made. This is only a template. Replace the example package names before running it.
#!/bin/sh
# Undo the changes. Edit the lists, then run.
# 1. Animations back to normal
adb shell settings put global window_animation_scale 1.0
adb shell settings put global transition_animation_scale 1.0
adb shell settings put global animator_duration_scale 1.0
# 2. Re-enable apps you disabled
for p in com.example.disabled1 com.example.disabled2; do
adb shell pm enable "$p"
done
# 3. Allow background running again for apps you restricted
for p in com.example.restricted1 com.example.restricted2; do
adb shell cmd appops set "$p" RUN_ANY_IN_BACKGROUND allow
adb shell am set-standby-bucket "$p" active
done
# 4. Re-add a battery-optimization exemption you removed
adb shell cmd deviceidle whitelist +com.example.app
# Uninstalled apps: reinstall from your app store.
# RAM Plus: change back in Settings.
Appendix B: Troubleshooting
| Problem | What to try |
|---|---|
adb devices is empty |
Try another cable or port, choose File transfer, then run adb kill-server && adb start-server. |
unauthorized |
Unlock the phone and accept the prompt; revoke USB debugging authorizations and reconnect; on Samsung, turn off Auto Blocker temporarily. |
| An app stopped working after you disabled it | Run adb shell pm enable <package>. |
| Notifications stopped | Restore background access and check Samsung Deep sleeping apps. |
| An app keeps coming back after being disabled | Some system apps re-enable themselves. Samsung Keyboard did this; leave it alone. |
| "Shell does not have permission" or "only root can…" | adb can't do that without root. Use Settings or skip it. |
| The phone is slower after changes | Roll back the last batch and change one thing at a time. |
| You lost access to an account after removing an app | Reinstall the app and use your recovery codes. |