Android need Garbage Collection

Brave Browser Mobile Support
,
1

Troubleshooting technical issues is much easier when both the user and support agent practice clear communication. For this reason, we have provided the template below for you to fill out with information about your issue. Please provide as much detail as possible so we can most efficiently resolve your problem.

Description of the issue: Cache accumulates to >1 GB and Brave just refuses to work.

How can this issue be reproduced?

  1. Just actively use brave on image intense websites for a day. Cache fills to stupid levels.

Expected result: Brave refuces to load any more pages over 1 GB

Brave Version( check About Brave): the last 10 versions

Mobile Device details. Samsung 10 inch Galaxy Tab S10 FE

Additional Information: I have force close Brave and manually clear cache and data to restore function. Brave should clear older cache items when it exceeds 200MB or so.

2

@Abccba

ChatGPT response - what you might try:

:gear: 1. Clear browsing data (manual, but most effective)

Path: Settings → Privacy → Clear browsing data

You can clear:

  • Cached images and files
  • Cookies and site data
  • Browsing history

:backhand_index_pointing_right: Tip: Set time range to “All time” for maximum impact.

Reality check:
This is the only reliable way to immediately shrink cache without nuking the app.

:broom: 2. Auto-clear on exit (partial mitigation)

Path: Settings → Privacy → Clear data on exit

Lets you automatically clear:

  • Cookies
  • History

:warning: Limitation:

  • Does NOT fully clear cached images/files
  • So it helps tracking/privacy, but won’t stop cache buildup entirely

:brain: 3. Storage usage view (to monitor the problem)

Path: Settings → About → Storage

Shows:

  • App size
  • User data
  • Cache

:backhand_index_pointing_right: Useful to confirm whether:

  • Growth is in cache (clearable)
  • Or user data (harder problem)

:prohibited: 4. Disable background video / media autoplay

Path: Settings → Site settings → Media

Reducing autoplay:

  • Lowers number of large media files cached
  • Helps on “image/video intense sites”

:stop_sign: 5. Shields (indirect but important)

Path: Per-site or global Shields settings

Block:

  • Trackers
  • Ads
  • Scripts (optional)

:backhand_index_pointing_right: Why it matters:

  • Many heavy assets = ads, trackers, CDNs
  • Blocking them = less stuff cached

:chart_decreasing: 6. Reduce tab buildup (very relevant)

Brave doesn’t aggressively unload tabs on Android.

Try:

  • Settings → Tabs → enable “Close tabs on exit”
  • Or manually close old tabs

:backhand_index_pointing_right: Each tab can retain cached resources and memory pressure.

:test_tube: 7. Brave flags (experimental, limited usefulness)

Path: brave://flags

You might find Chromium flags related to:

  • Disk cache size
  • Cache behavior

:warning: But:

  • Most are not reliable on Android
  • Often ignored or reset
  • Not officially supported by Brave

:mobile_phone: 8. Android system-level controls (outside Brave)

These matter more than people expect:

App info → Storage → Clear cache

  • Clears only cache (safe)
  • Faster than in-browser UI sometimes

Storage restriction

Some Android versions let you:

  • Restrict background activity
  • Limit storage indirectly

:construction: What’s missing (the core issue)

There is no setting in Brave Android for:

  • Max cache size (e.g., 200 MB cap)
  • Automatic LRU cache eviction control
  • Scheduled cache cleanup

:backhand_index_pointing_right: That’s why users end up doing:

“Force close + clear cache + clear data”

:compass: Practical combo that actually works

For someone hitting this issue regularly:

  • Enable Close tabs on exit
  • Turn on aggressive Shields
  • Disable autoplay
  • Periodically:
    • Clear cache (not full data)
  • Monitor storage in Settings

:brain: Bottom line

Brave Android gives you tools to reduce incoming cache, but not to control or cap it directly.

That lack of cache size management - is exactly why the Brave Community complaints keep resurfacing.

ChatGPT - some issues at GitHub:

:receipt: Key GitHub issues (cache / storage related)

1. “Disable or limit disk cache”

  • :link: View issue #5311
  • Summary:
    • User explicitly asks for a way to limit or disable cache size
    • Mentions Chromium flags like:

--disk-cache-size=1

  • Status:
    • Open question / feature request (not really implemented)

:backhand_index_pointing_right: This directly supports your observation:

There is no built-in way to cap cache (e.g., 200 MB)

2. “Expose a way to clear Service Worker cache”

  • :link: View issue #47275
  • Summary:
    • Reports that service worker cache is not cleared by normal “clear browsing data”
    • Stored separately and persists unexpectedly
  • Status:
    • Closed as not planned

:backhand_index_pointing_right: This is important because it shows:

  • Even when users think they cleared cache…
  • Some cache layers remain untouched

3. “DNS cache doesn’t get cleared”

  • :link: View issue #34547
  • Summary:
    • Internal cache (DNS) persists even after clearing via UI
  • Status:
    • Open

:backhand_index_pointing_right: Not about disk size directly, but reinforces the pattern:

  • Cache systems in Brave are fragmented and not fully controllable

4. Older but relevant: cache growth / storage design issues

  • :link: View issue #4947
  • Summary:
    • Cache stored in a way that causes huge storage growth (GBs over time) in backups
  • Status:
    • Closed (desktop/macOS), but illustrates design behavior

:backhand_index_pointing_right: Shows a long-standing theme:

  • Brave cache can grow very large if not managed

:brain: What’s notable across these issues

When you line them up, a pattern becomes pretty clear:

1. No cache size control

  • Users ask for limits → not implemented

2. Cache is split into multiple systems

  • Disk cache
  • Service worker cache
  • DNS cache
  • Possibly media cache

:backhand_index_pointing_right: And they’re not all cleared together

3. “Clear cache” ≠ actually clear everything

  • Confirmed by issue #47275:
    • Some storage survives cleanup

4. Long-standing behavior (years)

  • Requests go back to 2019 and earlier
  • Still not fully addressed