dumpsys و چند نسخه اسکریپت اختصاصی استفاده کردم تا اول یک TreeSize قابل اتکا از بخشهای قابلدسترسی بسازم، بعد بقایای بازیها و Cacheهای واضح را پیدا کنم، حذفها را مرحلهای انجام دهم و برای موارد مشکوک قبل از حذف Backup روی PC بگیرم. این مقاله مسیر واقعی همان پروژه را مستند میکند: از اولین خطای دانلود ADB تا Audit v1.3، پیدا کردن OBBهای یتیم، پاکسازی چند گیگابایت داده بلااستفاده، بررسی محدودیتهای `/data` و رسیدن به یک روش قابل تکرار برای عیبیابی حافظه Android بدون Root.محیط واقعی پروژه
تمام تستهای این مقاله روی دستگاه واقعی زیر انجام شد. این مشخصات از خروجی ADB و گزارشهای خود پروژه استخراج شدهاند و برای بازتولید رفتارها اهمیت دارند.
| مولفه | مقدار ثبتشده |
|---|---|
| گوشی | Xiaomi POCO X3، مدل M2007J20CG |
| Android | Android 12، SDK 31 |
| MIUI | V14.0.2.0.SJGMIXM |
| PowerShell | PowerShell 7.6.4 |
| ADB | Android Debug Bridge 1.0.41، Platform Tools 37.0.1 |
| ADB path | D:\AI\poco-x3\platform-tools\adb.exe |
| Project root | D:\AI\poco-x3 |
| Internal shared storage | /storage/emulated/0 |
| microSD | /storage/24E5-905A |
اسکریپتهای Audit با حداقل PowerShell 5.1 نوشته شدند، اما Runهای این پروژه با PowerShell 7.6.4 اجرا شدند. برای آرشیو گزارشها نیز از 7-Zip در صورت وجود استفاده شد و فرمت ترجیحی پروژه 7z + LZMA2 + Ultra + Solid بود.
هدف پروژه
هدف فقط پیدا کردن «بزرگترین فایل» نبود. من میخواستم چند سؤال را با شواهد پاسخ بدهم: حافظه واقعی کجا مصرف شده است؟ کدام فایلها متعلق به برنامههای حذفشدهاند؟ کدام مسیرها فقط Cache، Log یا Trash هستند؟ کدام فایلها ممکن است داده شخصی باشند؟ و آیا میتوان قبل از هر حذف نامطمئن یک Backup قابل بررسی روی PC گرفت؟
از همان ابتدا یک اصل برای پروژه تعیین کردم: مسیر پیشفرض باید Read-only باشد. یعنی Audit نباید هیچ فایل یا دیتایی را خودش پاک کند. Cleanup تنها بعد از مشاهده شواهد، بررسی Package و در موارد لازم Backup انجام میشود.
اولین Audit
نسخه اولیه اسکریپت با نام POCO-X3-Storage-Audit.ps1 ساخته شد تا کل /storage/emulated/0 را Recursive بررسی کند، اندازه فایلها را با stat بگیرد، حجم تجمعی پوشهها را محاسبه کند و خروجی CSV و HTML بسازد.
اولین Run در 19 اوت 2026 ساعت 23:50:12 شروع شد، اما قبل از رسیدن به اسکن گوشی شکست خورد. علت، دانلود خودکار Android Platform Tools بود:
[2026-08-19 23:50:12.895] [INFO] ADB not found. Downloading official Google Platform Tools...
[2026-08-19 23:50:13.998] [ERROR] Response status code does not indicate success: 404 (Not Found).در این مرحله هیچ اسکن یا Cleanupی انجام نشده بود. مشکل فقط Bootstrap ابزار بود. برای نسخه بعدی چند روش دانلود در نظر گرفته شد، اما در عمل Platform Tools را دستی گرفتم و در مسیر پروژه Extract کردم.
راهاندازی ADB
بعد از Extract کردن Platform Tools، مسیر ADB را موقتاً به PATH همان پنجره PowerShell اضافه کردم:
$env:PATH = "D:\AI\poco-x3\platform-tools;$env:PATH"
adb version
adb devicesخروجی نسخه ADB در همان Run ثبت شد:
Android Debug Bridge version 1.0.41
Version 37.0.1-15733141
Installed as D:\AI\poco-x3\platform-tools\adb.exe
Running on Windows 10.0.26200گوشی ابتدا با وضعیت unauthorized دیده شد:
List of devices attached
88f99b0d unauthorizedبعد از تأیید پیام USB debugging روی گوشی، وضعیت به device تغییر کرد و ارتباط آماده شد. برای انتشار عمومی، Serial دستگاه باید Sanitise شود و نباید در Repository یا گزارش نمونه باقی بماند.
Audit نسخه 1.1
نسخه POCO-X3-Storage-Audit-v1.1.ps1 در 19 اوت 2026 ساعت 23:59:36 اجرا شد. اسکن کامل فایلهای قابلدسترسی تا 20 اوت ساعت 00:03:28 ادامه داشت و 10,356 فایل پیدا شد.
[2026-08-19 23:59:36.525] [INFO] Device: Xiaomi M2007J20CG | Android 12 | SDK 31
[2026-08-19 23:59:36.575] [INFO] Scanning every ADB-readable file under /storage/emulated/0 ...
[2026-08-20 00:03:28.912] [PASS] Files discovered: 10356
[2026-08-20 00:03:29.717] [PASS] Audit completed successfully.بزرگترین فایلها در همان Run دو OBB مربوط به KOTOR II بودند:
1.78 GB /storage/emulated/0/Android/obb/com.aspyr.swkotorii/main.213.com.aspyr.swkotorii.obb
1.73 GB /storage/emulated/0/Android/obb/com.aspyr.swkotorii/patch.14.com.aspyr.swkotorii.obbاما مهمتر از خود OBBها، تناقضی بود که این Run نشان داد. مجموع فایلهای قابلمشاهده حدود 6.76GB بود، در حالی که df نشان میداد 42GB از پارتیشن 45GB مصرف شده است:
Filesystem Size Used Avail Use% Mounted on
/dev/fuse 45G 42G 3.3G 93% /storage/emulatedاین تفاوت نشان داد که اسکن Shared Storage بهتنهایی نمیتواند مصرف واقعی `/data` را توضیح دهد.
Full Audit
برای حل این محدودیت، نسخههای Full Audit ساخته شدند. v1.2 علاوه بر فایلها، Packageهای نصبشده و خروجی dumpsys diskstats را بررسی میکرد و v1.3 خروجی TreeSize را هم اضافه کرد.
نسخه 1.2
Run نسخه v1.2 در 20 اوت 2026 ساعت 00:34:34 شروع شد و ساعت 00:38:02 با موفقیت تمام شد. مهمترین خروجی آن تشخیص Orphan Candidateها بود:
3.51 GB /storage/emulated/0/Android/obb/com.aspyr.swkotorii
90.72 MB /storage/emulated/0/Android/obb/com.roadhousegames.carnageنسخه 1.3
v1.3 در 20 اوت ساعت 01:10:25 اجرا شد و علاوه بر Audit، چهار گزارش TreeSize ساخت:
TREESIZE.txt
TREESIZE-folders-only.txt
TREESIZE-folders.csv
TREESIZE-folders-and-files.csvاین نسخه علاوه بر نمایش سلسلهمراتبی پوشهها، امکان Sort و Filter کردن ساختار در Excel یا PowerShell را فراهم کرد. بعد از اولین Cleanup نیز v1.3 دوباره در 20 اوت ساعت 11:12:40 اجرا شد تا وضعیت جدید مبنای ادامه بررسی باشد.
بقایای بازیها
قبل از حذف OBBهای بازی، فقط به اسم پوشه اکتفا نکردم. با Package Manager بررسی کردم که آیا Packageهای متناظر هنوز نصب هستند یا نه:
adb shell pm list packages | findstr /i "com.aspyr.swkotorii"
adb shell pm list packages | findstr /i "com.roadhousegames.carnage"
adb shell pm list packages | findstr /i "com.worms4.app"هیچکدام خروجی ندادند. سپس حجم واقعی مسیرها با du تأیید شد:
3.5G /storage/emulated/0/Android/obb/com.aspyr.swkotorii
91M /storage/emulated/0/Android/obb/com.roadhousegames.carnage
249M /storage/emulated/0/Android/obb/Worms-4-v1.0.419806(www.farsroid.com)در نتیجه KOTOR II و Carnage بهعنوان Orphan تأیید شدند. Worms هم نصب نبود، اما ساختار پوشه آن Nested بود و همین موضوع یک ضعف v1.2/v1.3 را آشکار کرد: Orphan Detection سطح اول همیشه پوشههای واسط غیر-Package را درست تشخیص نمیدهد.
دو مسیر اول حذف شدند. حذف Worms در Attempt اول به دلیل وجود پرانتز در نام پوشه با خطای Shell شکست خورد:
/system/bin/sh: syntax error: unexpected '('این یک Root Cause ساده ولی مهم بود: Quoteگذاری روی سمت PowerShell بهتنهایی کافی نبود و باید کل Command ارسالی به Shell هم Quote میشد. Attempt اصلاحشده:
adb shell "rm -rf '/storage/emulated/0/Android/obb/Worms-4-v1.0.419806(www.farsroid.com)'"بعد از Retest، هر سه مسیر با REMOVED تأیید شدند. فضای آزاد از 5.4GB به 9.3GB رسید:
قبل: 45G total | 40G used | 5.4G free | 88%
بعد: 45G total | 36G used | 9.3G free | 80%این مرحله یک Fix واقعی و Validated بود، چون هم وجود نداشتن Packageها، هم حجم مسیرها، هم حذف آنها و هم تغییر df ثبت شد.
Gallery و Bazaar
بعد از OBBها دو مصرفکننده واضح دیگر بررسی شدند: Cache گالری MIUI و APKهای دانلودشده توسط Bazaar.
گالری 755MB در External Data داشت و تقریباً تمام آن زیر gallery_disk_cache بود:
755M .../com.miui.gallery/files/gallery_disk_cache
594M .../gallery_disk_cache/full_size
160M .../gallery_disk_cache/small_sizeBazaar نیز 596MB داشت که تقریباً تمام آن در files/apk قرار گرفته بود. فایلها شامل Base APK و Split APK برنامههایی مانند Gmail، Messages، Google Drive، TTS و Calendar بودند. این فایلها APKهای نصبشده در `/data/app` نبودند؛ بلکه فایلهای دانلودی Bazaar در External Data خود برنامه بودند.
هر دو برنامه ابتدا Force Stop شدند و فقط مسیرهای Cache/Downloaded APK حذف شدند:
adb shell am force-stop com.miui.gallery
adb shell am force-stop com.farsitel.bazaar
adb shell "rm -rf '/storage/emulated/0/Android/data/com.miui.gallery/files/gallery_disk_cache'"
adb shell "rm -rf '/storage/emulated/0/Android/data/com.farsitel.bazaar/files/apk'"بعد از حذف، حجم External Data گالری به 28KB و Bazaar به 147KB رسید و فضای آزاد به حدود 11GB افزایش پیدا کرد. این مرحله نیز با اندازهگیری مجدد مسیرها و df تأیید شد.
Trash و Cacheها
Audit جدید چند مسیر واضح دیگر پیدا کرد. دو مورد اصلی Trash/Recycle بودند:
/storage/emulated/0/DCIM/.globalTrash ≈ 206 MB
/storage/emulated/0/cleanmaster/PicRecycle ≈ 186 MBاین دو مسیر بعد از بررسی حذف شدند و وجود نداشتن آنها با du ... || echo REMOVED تأیید شد.
در مرحله بعد Cacheهای External چند برنامه حذف شد:
/Android/data/com.miui.cleaner/cache
/Android/data/com.miui.videoplayer/cache
/Android/data/org.telegram.messenger/cache
/Android/data/ir.nasim/cacheقبل از حذف، برنامهها Force Stop شدند. سپس لاگهای حجیم Xiaomi Wearable، Bale و Happ Proxy بررسی شدند. مسیرها صراحتاً Log بودند و اندازههای ثبتشده تقریباً 54MB، 63MB و 51MB بود:
/Android/data/com.xiaomi.wearable/files/log
/Android/data/ir.nasim/files/logs
/Android/data/com.happproxy/files/assets/logsاین Logها نیز بعد از Force Stop برنامه مربوطه حذف شدند. در Happ Proxy فقط پوشه Logs حذف شد؛ فایلهای اجرایی/دادهای مثل geoip.dat و geosite.dat نگه داشته شدند، چون بخشی از داده عملکرد برنامه بودند و Cache یا Log محسوب نمیشدند.
Backup قبل حذف
مهمترین تغییر رویکرد پروژه زمانی بود که به برنامه com.sfiord.KianamErtebat رسیدم. مسیر زیر حدود 248MB Cache داشت:
/storage/emulated/0/Android/data/com.sfiord.KianamErtebat/files/Care/Care/app_cacheاما محتوای Cache فقط فایلهای موقت ناشناس نبود؛ 65 فایل واقعی شامل MP4 و JPG داخل آن قرار داشت. در مقابل، /storage/emulated/0/Download/Care فقط 4 فایل و حدود 18MB داشت. بنابراین نمیتوانستم فرض کنم همه Cacheها نسخه دیگری دارند.
در این مرحله بهجای حذف مستقیم، Backup روی PC گرفتم:
$BackupRoot = "D:\AI\poco-x3\backup\PreCleanup-Care-$(Get-Date -Format yyyyMMdd-HHmmss)"
New-Item -ItemType Directory -Force $BackupRoot
adb pull "/storage/emulated/0/Android/data/com.sfiord.KianamErtebat/files/Care/Care/app_cache" "$BackupRoot\app_cache"
adb pull "/storage/emulated/0/Download/Care" "$BackupRoot\Download-Care"خروجی Backup در 20 اوت 2026 حدود ساعت 11:39 ثبت شد:
app_cache/: 65 files pulled, 0 skipped.
Download/Care/: 4 files pulled, 0 skipped.تعداد فایلها روی PC دوباره شمرده شد و دقیقاً 65 و 4 فایل بود. مجموع Backup برابر 264.91MB شد. بعد از این Validation، برنامه Force Stop شد و فقط app_cache حذف شد. External Data آن برنامه از حدود 252MB به 4.6MB رسید.
این الگو از آن نقطه به بعد به سیاست پیشنهادی پروژه تبدیل شد: هر چیزی که ظاهراً Cache است ولی محتوای کاربرمانند دارد، اول روی PC Backup و Verify شود و بعد پاک شود.
فضای پنهان /data
بعد از پاکسازی Shared Storage، یک سؤال باقی ماند: چرا هنوز `/data` حدود 35GB مصرف دارد، در حالی که کل فایلهای قابل مشاهده در `/storage/emulated/0` کمتر از 1GB شدهاند؟
تلاش برای پیمایش مستقیم مسیرهای خصوصی با ADB معمولی به نتیجه زیر رسید:
du: /data: Permission denied
du: /data/app: Permission denied
du: /data/data: Permission denied
du: /data/user/0: Permission deniedاین نتیجه نشان داد محدودیت اصلی دیگر اسکریپت نبود؛ Sandbox و Permissionهای Android 12 مانع خواندن مستقیم Private App Data میشدند. بنابراین برای Attribution از dumpsys diskstats استفاده کردم.
خروجی ثبتشده در آخرین بررسی:
App Size: 10878906880
App Data Size: 7227359862
App Cache Size: 1710006784
Photos Size: 27910144
Videos Size: 315392
Other Size: 750166016در همان زمان df برای `/data` این وضعیت را نشان میداد:
Filesystem Size Used Avail Use% Mounted on
/dev/block/sda16 45G 35G 10G 77% /data/user/0پس بخش قابل توجهی از مصرف واقعی در App binary، Private App Data و Private Cache بود؛ چیزی که TreeSize ساده روی Shared Storage نمیتوانست نمایش دهد.
برنامههای حجیم
v1.3 آرایههای dumpsys diskstats را به دو CSV مرتب تبدیل کرد: apps-by-storage.csv و apps-by-cache.csv. این مرحله کمک کرد بهجای حدس، Packageهای واقعی را بر اساس App/Data/Cache رتبهبندی کنم.
| Package | حجم کل | Cache |
|---|---|---|
com.google.android.gms | 1479.37 MB | 4.39 MB |
com.instagram.android | 1340.8 MB | 265.73 MB |
com.android.chrome | 1274.58 MB | 544.9 MB |
com.miui.gallery | 1016.41 MB | 0.12 MB |
com.google.android.apps.photos | 854.77 MB | 90.54 MB |
ir.nasim | 674.23 MB | 143.89 MB |
com.whatsapp.w4b | 660.44 MB | 10.96 MB |
بزرگترین Private Cache مشخصشده Chrome بود با 544.9MB، سپس Instagram با 265.73MB و Bale با 143.89MB. این دادهها Snapshot هستند و نباید بهعنوان مقدار ثابت در دستگاه دیگر یا حتی Run بعدی استفاده شوند.
خطر pm clear
در این مرحله تفاوت Cache Clearing و Data Clearing اهمیت پیدا کرد. فرمان زیر Cache-only نیست:
adb shell pm clear PACKAGEpm clear میتواند کل Data برنامه را حذف کند؛ یعنی Login، دیتابیس، Preference و سایر اطلاعات خصوصی. در جریان پروژه یک بار همین Command با Placeholder لفظی PACKAGE اجرا شد و خروجی Failed گرفت، بنابراین هیچ Package واقعی پاک نشد.
برای Private Cacheهایی که ADB بدون Root اجازه حذف انتخابی آنها را نمیدهد، روش محافظهکارانه باز کردن App Info و استفاده از گزینه Clear cache خود Android بود:
adb shell am start -a android.settings.APPLICATION_DETAILS_SETTINGS -d package:com.android.chromeدر آخرین وضعیت ثبتشده، پاکسازی Private Cacheهای Chrome، Instagram و سایر Packageهای بزرگ هنوز بهصورت مرحله بعدی پیشنهاد شده بود و Validation اجرایی برای آنها در اطلاعات موجود ثبت نشده است. بنابراین این بخش هنوز Not Tested باقی میماند.
بررسی Fastboot
در میانه پروژه موضوع Root و Backup کاملتر مطرح شد. قبل از هر Unlock، وضعیت Bootloader با ADB بررسی شد:
ro.boot.flash.locked = 1
ro.boot.vbmeta.device_state = locked
ro.boot.verifiedbootstate = green
ro.boot.veritymode = enforcingبنابراین Bootloader در وضعیت Locked و Verified Boot در حالت Green بود. گوشی با adb reboot bootloader وارد Fastboot شد، اما Windows دستگاه را با Driver صحیح بالا نیاورد.
Device Manager/PnP این Device را با Hardware ID زیر و Problem Code 28 گزارش کرد:
USB\VID_18D1&PID_D00D\<DEVICE_SERIAL>
Device Description: Android
Class Name: Unknown
Status: Problem
Problem Code: 28 (CM_PROB_FAILED_INSTALL)در نتیجه fastboot devices خروجی نداد و fastboot getvar unlocked روی < waiting for any device > ماند. این Issue در پروژه حل نشد چون تصمیم گرفتم فعلاً Cleanup و Backup را مقدم بدانم. هیچ Unlock، Flash، Erase یا Root روی گوشی انجام نشد.
خطاها و درسها
این پروژه چند Attempt ناموفق یا ناقص داشت که حذف کردنشان از مستندات، بخش مهمی از مسیر عیبیابی را از بین میبرد.
| مشکل | نتیجه | وضعیت |
|---|---|---|
| دانلود خودکار Platform Tools با Invoke-WebRequest | 404؛ اسکن شروع نشد | Superseded با دانلود دستی و ADB محلی |
| حذف Worms بدون Quote مناسب برای Shell | Syntax error روی پرانتز | Fix و Retest موفق |
| Orphan Detection سطح اول | پوشه واسط Worms را کامل تشخیص نداد | Known limitation |
| Direct du روی `/data` | Permission denied | Accepted limitation بدون Root |
| Fastboot روی Windows | Device Code 28 / Driver missing | Unresolved، خارج از Scope فعلی |
| Private Cache cleanup | روش App Info پیشنهاد شد | Not Tested در آخرین وضعیت |
مسیر پیشنهادی
بعد از تجربه این پروژه، اگر بخواهم همین کار را از ابتدا روی یک گوشی Android غیرروتشده تکرار کنم، مسیر تمیزتر برای خواننده این است:
- Developer Options و USB debugging را فعال کنید و با
adb devicesاتصال را تأیید کنید. - قبل از حذف هر چیزی،
df -h /dataوdf -h /storage/emulated/0را ثبت کنید. - Shared Storage را با
find/statوduاسکن کنید و TreeSize بسازید. - Packageهای نصبشده را با
pm list packagesبررسی کنید و OBB/Data مشکوک را با Package Manager تطبیق دهید. - برای مسیرهای واضح Cache/Log/Trash، برنامه را Force Stop کنید و فقط همان مسیر تأییدشده را حذف کنید.
- اگر یک Cache شامل عکس، ویدئو یا دادهای است که ممکن است برای کاربر مهم باشد، اول با
adb pullروی PC Backup بگیرید و تعداد/حجم فایلها را Verify کنید. - برای فضای خصوصی از
dumpsys diskstatsاستفاده کنید و Packageها را بر اساس App/Data/Cache رتبهبندی کنید. - برای Private Cache از Clear cache خود Android استفاده کنید؛ از
pm clearبرای Cleanup معمولی استفاده نکنید. - بعد از هر مرحله دوباره
dfو Audit کامل بگیرید تا اثر واقعی تغییر مشخص شود.
خروجیهای پروژه
اسکریپتهای Full Audit برای هر Run یک پوشه Timestampدار زیر D:\AI\poco-x3\reports میسازند. مهمترین فایلها عبارتاند از:
SUMMARY.txt
REPORT.html
run.log
df-all.txt
dumpsys-diskstats.txt
packages-all.txt
packages-user.txt
apps-by-storage.csv
apps-by-cache.csv
internal-all-files.csv
internal-all-folders.csv
internal-large-files-100MB-plus.csv
extensions-by-size.csv
orphan-candidates.csv
android-data-obb-media-package-check.csv
cleanup-candidates-readonly.csv
TREESIZE.txt
TREESIZE-folders-only.txt
TREESIZE-folders.csv
TREESIZE-folders-and-files.csvاین خروجیها برای بررسی دستی، Excel، PowerShell، مقایسه Runها و توسعه ابزارهای بعدی قابل استفادهاند. Diagnostic bundle نیز در صورت وجود 7-Zip با 7z/LZMA2 ساخته میشود.
Timeline پروژه
رویدادهای زیر فقط از Timestampهای ثبتشده در Runها و فایلها استخراج شدهاند.
| زمان | رویداد | نتیجه |
|---|---|---|
| 2026-08-19 23:50 | اجرای Audit اولیه | دانلود ADB با 404 شکست خورد |
| 2026-08-19 23:59 | Audit v1.1 | 10,356 فایل پیدا شد |
| 2026-08-20 00:03 | پایان v1.1 | گزارش و Archive ساخته شد |
| 2026-08-20 00:34 | Full Audit v1.2 | Orphan Candidateها استخراج شدند |
| 2026-08-20 01:10 | Full Audit v1.3 | TreeSize اضافه شد |
| 2026-08-20 11:12 | Audit مجدد v1.3 | وضعیت بعد از Cleanup ثبت شد |
| 2026-08-20 11:39 | Backup Care روی PC | 65 + 4 فایل، 0 skipped |
برای Cleanupهای میانی Timestamp دقیق همه Commandها در اطلاعات موجود ثبت نشده است؛ بنابراین فقط ترتیب آنها قابل اتکا است و زمان ساختگی برایشان اضافه نشده است.
وضعیت نهایی پروژه
آخرین نسخه قابل اثبات اسکریپت POCO-X3-Storage-Full-Audit-v1.3.ps1 است. آخرین Full Audit ثبتشده در 20 اوت 2026 ساعت 11:12 اجرا شد و با PASS تمام شد.
| موضوع | وضعیت | مدرک |
|---|---|---|
| Audit Shared Storage | Validated | Runهای v1.1 تا v1.3 |
| TreeSize | Validated | چهار فایل TreeSize ساخته شد |
| حذف OBBهای بازیهای حذفشده | Validated | Package check + REMOVED + df |
| Gallery/Bazaar cleanup | Validated | حجم مسیر قبل/بعد + df |
| Trash/Recycle cleanup | Validated | REMOVED برای هر دو مسیر |
| Care backup-before-delete | Validated | 65/65 و 4/4 فایل، 0 skipped |
| Direct private-data scan | محدود | Permission denied بدون Root |
| Private cache cleanup | Not Tested | فقط Candidateها رتبهبندی شدند |
| Fastboot driver | Unresolved | Windows Code 28 |
| Root/Bootloader unlock | Not Performed | Bootloader همچنان Locked |
| Full pre-unlock backup | Not Completed | فقط Backup موضعی Care انجام شد |
خلاصه پروژه
مشکل اصلی، پر شدن حافظه داخلی POCO X3 بدون تمایل به Factory Reset بود. اسکن اولیه نشان داد بخش بزرگی از مصرف واقعی با Shared Storage توضیح داده نمیشود. با توسعه Audit از نسخه اولیه تا v1.3، فایلهای حجیم، OBBهای یتیم، Cacheها، Logها، Trashها و Packageهای پرمصرف شناسایی شدند. چند مرحله Cleanup با Verification انجام شد و برای Cache مشکوک Care، Backup روی PC قبل از حذف گرفته شد.
در آخرین وضعیت ثبتشده، پارتیشن `/data` حدود 45GB ظرفیت، 35GB مصرف و 10GB فضای آزاد داشت. بخش بزرگی از مصرف باقیمانده مربوط به App Size، Private App Data و Private Cache است. محدودیت مهم فعلی این است که ADB بدون Root نمیتواند `/data/user/0` را مستقیم پیمایش کند؛ برای همین Attribution از `dumpsys diskstats` انجام میشود. Root و Unlock هنوز انجام نشدهاند و Fastboot Driver ویندوز نیز در وضعیت Code 28 باقی مانده است.
سؤالات متداول
آیا ADB بدون Root میتواند کل حافظه Android را فایلبهفایل بخواند؟
خیر. در این پروژه دسترسی مستقیم به `/data`، `/data/app`، `/data/data` و `/data/user/0` با Permission denied رد شد. برای اندازهگیری Private App Storage از گزارشهای Android مانند dumpsys diskstats استفاده شد.
آیا حذف پوشه Android/obb امن است؟
فقط وقتی Package متناظر دیگر نصب نباشد و مسیر با شواهد بررسی شده باشد. در این پروژه قبل از حذف OBBها، نصب نبودن Packageها با pm list packages تأیید شد.
آیا pm clear همان Clear cache است؟
خیر. pm clear میتواند کل Data برنامه را حذف کند. برای پاک کردن Cache خصوصی، در این پروژه استفاده از گزینه Clear cache داخل App Info پیشنهاد شد.
چرا TreeSize کمتر از df حجم نشان میدهد؟
TreeSize روی `/storage/emulated/0` فقط فایلهای Shared Storage قابلدسترسی را جمع میکند، اما df /data App binaries، Private Data، Private Cache و سایر دادههای پارتیشن را هم حساب میکند.
برای فایلهای مشکوک چه روشی کم ریسکتر است؟
Backup روی PC با adb pull، سپس Verify تعداد و حجم فایلها، Force Stop برنامه، حذف فقط مسیر تأییدشده و در پایان اندازهگیری مجدد.
آیا در این پروژه گوشی Root شد؟
خیر. Bootloader در وضعیت Locked و Verified Boot در حالت Green ثبت شد. هیچ Unlock یا Flash انجام نشد.
جمعبندی
نتیجه اصلی این پروژه برای من این بود که «حافظه داخلی پر شده» در Android لزوماً یک مسئله File Manager نیست. ممکن است چند گیگابایت در OBBهای برنامههای حذفشده، Cacheهای قابل بازسازی، Logها و Trashها پنهان شده باشد، اما بخش مهم دیگری هم در Private App Data قرار دارد که بدون Root مستقیماً قابل پیمایش نیست.
ترکیب ADB، PowerShell، TreeSize سفارشی و dumpsys diskstats اجازه داد بدون Factory Reset و بدون Root، بخش زیادی از مصرف را بهصورت قابل دفاع شناسایی و چند مرحله Cleanup را Validate کنم. مهمتر از میزان فضای آزادشده، یک Workflow قابل تکرار شکل گرفت: اول اندازهگیری، بعد تشخیص مالکیت، سپس Backup در موارد نامطمئن، حذف محدود و در پایان Retest.
پروژه در این نقطه تمام نشده است. پاکسازی Private Cacheهای بزرگ، Backup کامل قبل از هر تصمیم برای Unlock و رفع Fastboot Driver هنوز باقی ماندهاند. بنابراین وضعیت نهایی، یک ابزار Audit و Cleanup مرحلهای معتبر است؛ نه یک راهحل کامل Root-level برای مشاهده تمام فایلهای `/data`.
