Reduce the in-memory blob storgae limit on Android

storage/browser/blob/README.md

 # Chrome's Blob Storage System Design
 
 Elaboration of the blob storage system in Chrome.
 
 # What are blobs?
 
 Please see the [FileAPI Spec](https://www.w3.org/TR/FileAPI/) for the full
 specification for Blobs, or [Mozilla's Blob documentation](
 https://developer.mozilla.org/en-US/docs/Web/API/Blob) for a description of how
 Blobs are used in the Web Platform in general. For the purposes of this
@@ skipping 64 matching lines @@
 size.
 
 # Blob Storage Limits
 
 We calculate the storage limits [here](
 https://cs.chromium.org/chromium/src/storage/browser/blob/blob_memory_controller.cc?q=CalculateBlobStorageLimitsImpl&sq=package:chromium).
 
 **In-Memory Storage Limit**
 
 * If the architecture is x64 and NOT Chrome OS or Android: `2GB`
-* Otherwise: `total_physical_memory / 5`
+* If Chrome OS: `total_physical_memory / 5`
+* If Android: `total_physical_memory / 100`
+
 
 **Disk Storage Limit**
 
 * If Chrome OS: `disk_size / 2`
-* If Android: `disk_size / 20`
+* If Android: `6 * disk_size / 100`
 * Else: `disk_size / 10`
 
 Note: Chrome OS's disk is part of the user partition, which is separate from the
 system partition.
 
 **Minimum Disk Availability**
 
 We limit our disk limit to accomidate a minimum disk availability. The equation
 we use is:
 
 `min_disk_availability = in_memory_limit * 2`
 
 ## Example Limits
 
-(All sizes in GB)
-
 | Device | Ram | In-Memory Limit | Disk | Disk Limit | Min Disk Availability |
 | --- | --- | --- | --- | --- | --- |
-| Cast | 0.5 | 0.1 | 0 | 0 | 0 |
-| Android Minimal | 0.5 | 0.1 | 8 | 0.4 | 0.2 |
-| Android Fat | 2 | 0.4 | 32 | 1.5 | 0.8 |
-| CrOS | 2 | 0.4 | 8 | 4 | 0.8 |
-| Desktop 32 | 3 | 0.6 | 500 | 50 | 1.2 |
-| Desktop 64 | 4 | 2 | 500 | 50 | 4 |
+| Cast | 512 MB | 102 MB | 0 | 0 | 0 |
+| Android Minimal | 512 MB | 5 MB | 8 GB | 491 MB | 10 MB |
+| Android Fat | 2 GB | 20 MB | 32 GB | 1.9 GB | 40 MB |
+| CrOS | 2 GB | 409 MB | 8 GB | 4 GB | 0.8 GB |
+| Desktop 32 | 3 GB | 614 MB | 500 GB | 50 GB | 1.2 GB |
+| Desktop 64 | 4 GB | 2 GB | 500 GB | 50 GB | 4 GB |
 
 # Common Pitfalls
 
 ## Creating Large Blobs Too Fast
 
 Creating a lot of blobs, especially if they are very large blobs, can cause
 the renderer memory to grow too fast and result in an OOM on the renderer side.
 This is because the renderer temporarily stores the blob data while it waits
 for the browser to request it. Meanwhile, Javascript can continue executing.
 Transfering the data can take a lot of time if the blob is large enough to save
 it directly to a file, as this means we need to wait for disk operations before
 the renderer can get rid of the data.
 
 ## Leaking Blob References
 
 If the blob object in Javascript is kept around, then the data will never be
-cleaned up in the backend. This will unnecessarily us memory, so make sure to
+cleaned up in the backend. This will unnecessarily use memory, so make sure to
 dereference blob objects if they are no longer needed.
 
 Similarily if a URL is created for a blob, this will keep the blob data around
 until the URL is revoked (and the blob object is dereferenced). However, the
 URL is automatically revoked when the browser context is destroyed.
 
 # How to use Blobs (Browser-side)
 
 ## Building
 All blob interaction should go through the `BlobStorageContext`. Blobs are
@@ skipping 197 matching lines @@
 
 The `BlobMemoryController` is responsable for:
 
 1. Determining storage quota limits for files and memory, including restricting
 file quota when disk space is low.
 2. Determining whether a blob can fit and the transportation strategy to use.
 3. Tracking memory quota.
 4. Tracking file quota and creating files.
 5. Accumulating and evicting old blob data to files to disk.