Test should expect fewer fonts on Android

Some Android flavors have less fonts than
the numbers assumed (IoT cases). Change
this to test for 10.

Bug: b/143273186
Test: Local test run.
Change-Id: If4c23ee990f1de28aceb2bf768dc815f4693ef7f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1957207Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Reviewed-by: Dominik Röttsches <drott@chromium.org>
Commit-Queue: Brett Kilty <brettk@google.com>
Cr-Commit-Position: refs/heads/master@{#723422}

content/browser/font_unique_name_lookup/font_unique_name_lookup_unittest.cc

@@ -105,17 +105,18 @@ TEST_F(FontUniqueNameLookupTest, TestHandleFailedRead) {
   blink::FontTableMatcher matcher(mapping);
 
   // AOSP Android Kitkat has 81 fonts, the Kitkat bot seems to have 74,
-  // Marshmallow has 149, Oreo 247, let's expect at least 50.
-  ASSERT_GT(matcher.AvailableFonts(), 50u);
+  // Marshmallow has 149, Oreo 247. There are other variants that are built
+  // with fewer fonts however. Be safer and assume 10 maximum.
+  ASSERT_GT(matcher.AvailableFonts(), 10u);
   ASSERT_TRUE(font_unique_name_lookup_->PersistToFile());
   ASSERT_TRUE(base::PathExists(
       font_unique_name_lookup_->TableCacheFilePathForTesting()));
   int64_t file_size;
   ASSERT_TRUE(base::GetFileSize(
       font_unique_name_lookup_->TableCacheFilePathForTesting(), &file_size));
-  // For 81 fonts minimumm, very conservatively assume we have at least 1k of
-  // data, it's rather around 30k in practice.
-  ASSERT_GT(file_size, 1024);
+  // For 10 fonts, assume we have at least 256 bytes of data, it's
+  // around 30k in practice on Kitkat with 81 fonts.
+  ASSERT_GT(file_size, 256);
   ASSERT_TRUE(font_unique_name_lookup_->LoadFromFile());
 
   // For each truncated size, reading must fail, otherwise we successfully read