Issue %3020 - Part 6: Clean up docs and some code comments.

Polish only, no code changes.

18 files changed, 26 insertions, 286 deletions

diff --git a/build/docs/androideclipse.rst b/build/docs/androideclipse.rst
deleted file mode 100644
index a8c048130..000000000
--- a/build/docs/androideclipse.rst
+++ /dev/null
@@ -1,90 +0,0 @@
-.. _build_androideclipse:
-
-========================
-Android Eclipse Projects
-========================
-
-The build system contains alpha support for generating Android Eclipse
-project files to aid with development.
-
-To generate Android Eclipse project files, you'll need to have a fully
-built and packaged tree::
-
-   mach build && mach package
-
-(This is because Eclipse itself packages an APK containing
-``omni.ja``, and ``omni.ja`` is only assembled during packaging.)
-
-Then, simply generate the Android Eclipse build backend::
-
-   mach build-backend -b AndroidEclipse
-
-If all goes well, the path to the generated projects should be
-printed (currently, ``$OBJDIR/android_eclipse``).
-
-To use the generated Android Eclipse project files, you'll need to
-have a recent version of Eclipse (see `Tested Versions`_) with the
-`Eclipse ADT plugin
-<http://developer.android.com/tools/sdk/eclipse-adt.html>`_
-installed. You can then import all the projects into Eclipse using
-*File > Import ... > General > Existing Projects into Workspace*.
-
-Updating Project Files
-======================
-
-As you pull and update the source tree, your Android Eclipse files may
-fall out of sync with the build configuration. The tree should still
-build fine from within Eclipse, but source files may be missing and in
-rare circumstances Eclipse's index may not have the proper build
-configuration.
-
-To account for this, you'll want to periodically regenerate the
-Android Eclipse project files. You can do this by running ``mach build
-&& mach package && mach build-backend -b AndroidEclipse`` from the
-command line. It's a good idea to refresh and clean build all projects
-in Eclipse after doing this.
-
-In future, we'd like to include an Android Eclipse run configuration
-or build target that integrates updating the project files.
-
-Currently, regeneration rewrites the original project files. **If
-you've made any customizations to the projects, they will likely get
-overwritten.** We would like to improve this user experience in the
-future.
-
-Troubleshooting
-===============
-
-If Eclipse's builder gets confused, you should always refresh and
-clean build all projects. If Eclipse's builder is continually
-confused, you can see a log of what is happening at
-``$OBJDIR/android_eclipse/build.log``.
-
-If you run into memory problems executing ``dex``, you should
-`Increase Eclipse's memory limits <http://stackoverflow.com/a/11093228>`_.
-
-The produced Android Eclipse project files are unfortunately not
-portable. Please don't move them around.
-
-Structure of Android Eclipse projects
-=====================================
-
-The Android Eclipse backend generates several projects spanning Fennec
-itself and its tests. You'll mostly interact with the *Fennec* project
-itself.
-
-In future, we'd like to expand this documentation to include some of
-the technical details of how the Eclipse integration works, and how to
-add additional Android Eclipse projects using the ``moz.build``
-system.
-
-Tested Versions
-===============
-
-===============    ====================================    =================
-OS                 Version                                 Working as of
-===============    ====================================    =================
-Mac OS X           Luna (Build id: 20130919-0819)          February 2014
-Mac OS X           Kepler (Build id: 20131219-0014)        February 2014
-Mac OS X 10.8.5    Kepler (Build id: 20130919-0819)        February 2014
-===============    ====================================    =================
diff --git a/build/docs/cppeclipse.rst b/build/docs/cppeclipse.rst
index 4492add47..3596a2f9a 100644
--- a/build/docs/cppeclipse.rst
+++ b/build/docs/cppeclipse.rst
@@ -18,14 +18,14 @@ built tree::
 
    mach build
 
-Then, simply generate the Android Eclipse build backend::
+Then, simply generate the Eclipse build backend::
 
    mach build-backend -b CppEclipse
 
 If all goes well, the path to the generated workspace should be
-printed (currently, ``$OBJDIR/android_eclipse``).
+printed.
 
-To use the generated Android Eclipse project files, you'll need to
+To use the generated Eclipse project files, you'll need to
 have a Eclipse CDT 8.3 (We plan to follow the latest Eclipse release)
 `Eclipse CDT plugin
 <https://www.eclipse.org/cdt/>`_
@@ -43,7 +43,7 @@ rare circumstances Eclipse's index may not have the proper build
 configuration.
 
 To account for this, you'll want to periodically regenerate the
-Android Eclipse project files. You can do this by running ``mach build
+Eclipse project files. You can do this by running ``mach build
 && mach build-backend -b CppEclipse`` from the
 command line.
 
diff --git a/build/docs/index.rst b/build/docs/index.rst
index 63e053757..75000aff3 100644
--- a/build/docs/index.rst
+++ b/build/docs/index.rst
@@ -33,7 +33,6 @@ integrated development environment (IDE)
 .. toctree::
    :maxdepth: 1
 
-   androideclipse
    cppeclipse
    visualstudio
 
diff --git a/build/docs/locales.rst b/build/docs/locales.rst
index 4705ed963..86c740218 100644
--- a/build/docs/locales.rst
+++ b/build/docs/locales.rst
@@ -17,84 +17,5 @@ like a re-packaging post-processing step.
 There are scripts in-tree in mozharness to orchestrate these re-packaging
 steps for `Desktop
 <https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/scripts/desktop_l10n.py>`_
-and `Android
-<https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/scripts/mobile_l10n.py>`_
 but they rely heavily on buildbot information so they are almost impossible to
 run locally.
-
-The following instructions are extracted from the `Android script with hg hash
-494289c7
-<https://dxr.mozilla.org/mozilla-central/rev/494289c72ba3997183e7b5beaca3e0447ecaf96d/testing/mozharness/scripts/mobile_l10n.py>`_,
-and may need to be updated and slightly modified for Desktop.
-
-Step by step instructions for Android
--------------------------------------
-
-This assumes that ``$AB_CD`` is the locale you want to repack with; I tested
-with "ar" and "en-GB".
-
-.. warning:: l10n repacks do not work with artifact builds.  Repackaging
-   compiles no code so supporting ``--disable-compile-environment`` would not
-   save much, if any, time.
-
-#. You must have a built and packaged object directory, or a pre-built
-   ``en-US`` package.
-
-   .. code-block:: shell
-
-      ./mach build
-      ./mach package
-
-#. Clone ``l10n-central/$AB_CD`` so that it is a sibling to your
-   ``mozilla-central`` directory.
-
-   .. code-block:: shell
-
-      $ ls -al
-      mozilla-central
-      ...
-      $ mkdir -p l10n-central
-      $ hg clone https://hg.mozilla.org/l10n-central/$AB_CD l10n-central/$AB_CD
-      $ ls -al
-      mozilla-central
-      l10n-central/$AB_CD
-      ...
-
-#. Copy your ``mozconfig`` to ``mozconfig.l10n`` and add the following.
-
-   ::
-
-      ac_add_options --with-l10n-base=../../l10n-central
-      ac_add_options --disable-tests
-      mk_add_options MOZ_OBJDIR=./objdir-l10n
-
-#. Configure and prepare the l10n object directory.
-
-   .. code-block:: shell
-
-      MOZCONFIG=mozconfig.l10n ./mach configure
-      MOZCONFIG=mozconfig.l10n ./mach build -C config export
-      MOZCONFIG=mozconfig.l10n ./mach build buildid.h
-
-#. Copy your built package and unpack it into the l10n object directory.
-
-   .. code-block:: shell
-
-      cp $OBJDIR/dist/fennec-*en-US*.apk ./objdir-l10n/dist
-      MOZCONFIG=mozconfig.l10n ./mach build -C mobile/android/locales unpack
-
-#. Run the ``compare-locales`` script to write locale-specific changes into
-   ``objdir-l10n/merged``.
-
-   .. code-block:: shell
-
-      MOZCONFIG=mozconfig.l10n ./mach compare-locales --merge-dir objdir-l10n/merged $AB_CD
-
-#. Finally, repackage using the locale-specific changes.
-
-   .. code-block:: shell
-
-      MOZCONFIG=mozconfig.l10n LOCALE_MERGEDIR=`realpath objdir-l10n/merged` ./mach build -C mobile/android/locales installers-$AB_CD
-
-   (Note the absolute path for ``LOCALE_MERGEDIR``.)  You should find a
-   re-packaged build at ``objdir-l10n/dist/fennec-*$AB_CD*.apk``.
diff --git a/build/docs/mozinfo.rst b/build/docs/mozinfo.rst
index 85ceb6657..758d4862f 100644
--- a/build/docs/mozinfo.rst
+++ b/build/docs/mozinfo.rst
@@ -62,8 +62,7 @@ bits
 buildapp
    The path to the XUL application being built.
 
-   For desktop Firefox, this is ``browser``. For Fennec, it's
-   ``mobile/android``. For B2G, it's ``b2g``.
+   For desktop Firefox, this is ``browser``.
 
 crashreporter
    Whether the crash reporter is enabled for this build.
@@ -107,9 +106,9 @@ nightly_build
 
 os
    The operating system the build is produced for. Values for tier-1
-   supported platforms are ``linux``, ``win``, ``mac``, ``b2g``, and
-   ``android``. For other platforms, the value is the lowercase version
-   of the ``OS_TARGET`` variable from ``config.status``.
+   supported platforms are ``linux`` and ``win``. For other platforms,
+   the value is the lowercase version of the ``OS_TARGET`` variable
+   from ``config.status``.
 
    Always defined.
 
diff --git a/build/docs/toolchains.rst b/build/docs/toolchains.rst
index eba640fa0..6ad460a1e 100644
--- a/build/docs/toolchains.rst
+++ b/build/docs/toolchains.rst
@@ -54,58 +54,3 @@ archive::
    $ ./mach python build/windows_toolchain.py create-zip vs2015u3
 
 The produced archive will be the argument to ``create-zip`` + ``.zip``.
-
-Firefox for Android with Gradle
-===============================
-
-To build Firefox for Android with Gradle in automation, archives
-containing both the Gradle executable and a Maven repository
-comprising the exact build dependencies are produced and uploaded to
-an internal Mozilla server.  The build automation will download,
-verify, and extract these archive before building.  These archives
-provide a self-contained Gradle and Maven repository so that machines
-don't need to fetch additional Maven dependencies at build time.
-(Gradle and the downloaded Maven dependencies can be both
-redistributed publicly.)
-
-Archiving the Gradle executable is straight-forward, but archiving a
-local Maven repository is not.  Therefore a special Task Cluster
-Docker image and job exist for producing the required archives.  The
-Docker image definition is rooted in
-``taskcluster/docker/android-gradle-build``.  The Task Cluster job
-definition is in
-``testing/taskcluster/tasks/builds/android_api_15_gradle_dependencies.yml``.
-The job runs in a container based on the custom Docker image and
-spawns a Sonatype Nexus proxying Maven repository process in the
-background.  The job builds Firefox for Android using Gradle and the
-in-tree Gradle configuration rooted at ``build.gradle``.  The spawned
-proxying Maven repository downloads external dependencies and collects
-them.  After the Gradle build completes, the job archives the Gradle
-version used to build, and the downloaded Maven repository, and
-exposes them as Task Cluster artifacts.
-
-Here is `an example try job fetching these dependencies
-<https://treeherder.mozilla.org/#/jobs?repo=try&revision=75bc98935147&selectedJob=17793653>`_.
-The resulting task produced a `Gradle archive
-<https://queue.taskcluster.net/v1/task/CeYMgAP3Q-KF8h37nMhJjg/runs/0/artifacts/public%2Fbuild%2Fgradle.tar.xz>`_
-and a `Maven repository archive
-<https://queue.taskcluster.net/v1/task/CeYMgAP3Q-KF8h37nMhJjg/runs/0/artifacts/public%2Fbuild%2Fjcentral.tar.xz>`_.
-These archives were then uploaded (manually) to Mozilla automation
-using tooltool for consumption in Gradle builds.
-
-To update the version of Gradle in the archive produced, update
-``gradle/wrapper/gradle-wrapper.properties``.  Be sure to also update
-the SHA256 checksum to prevent poisoning the build machines!
-
-To update the versions of Gradle dependencies used, update
-``dependencies`` sections in the in-tree Gradle configuration rooted
-at ``build.gradle``.  Once you are confident your changes build
-locally, push a fresh try build with an invocation like::
-
-   $ hg push-to-try -m "try: -b o -p android-api-15-gradle-dependencies"
-
-Then `upload your archives to tooltool
-<https://wiki.mozilla.org/ReleaseEngineering/Applications/Tooltool#How_To_Upload_To_Tooltool>`_,
-update the in-tree manifests in
-``mobile/android/config/tooltool-manifests``, and push a fresh try
-build.
diff --git a/build/moz-automation.mk b/build/moz-automation.mk
index e7fa16fcb..971bdddf9 100644
--- a/build/moz-automation.mk
+++ b/build/moz-automation.mk
@@ -15,7 +15,7 @@ ifndef JS_STANDALONE
 include $(topsrcdir)/toolkit/mozapps/installer/package-name.mk
 include $(topsrcdir)/toolkit/mozapps/installer/upload-files.mk
 
-# Clear out DIST_FILES if it was set by upload-files.mk (for Android builds)
+# Clear out DIST_FILES if it was set
 DIST_FILES =
 endif
 
diff --git a/dom/plugins/base/nsNPAPIPluginInstance.cpp b/dom/plugins/base/nsNPAPIPluginInstance.cpp
index 203c61a5c..6e35bf366 100644
--- a/dom/plugins/base/nsNPAPIPluginInstance.cpp
+++ b/dom/plugins/base/nsNPAPIPluginInstance.cpp
@@ -1000,8 +1000,7 @@ PluginTimerCallback(nsITimer *aTimer, void *aClosure)
   PLUGIN_LOG(PLUGIN_LOG_NOISY, ("nsNPAPIPluginInstance running plugin timer callback this=%p\n", npp->ndata));
 
   MAIN_THREAD_JNI_REF_GUARD;
-  // Some plugins (Flash on Android) calls unscheduletimer
-  // from this callback.
+  // Some plugins call unscheduletimer from this callback. Use a guard.
   t->inCallback = true;
   (*(t->callback))(npp, id);
   t->inCallback = false;
diff --git a/dom/system/nsDeviceSensors.cpp b/dom/system/nsDeviceSensors.cpp
index 3b6babc67..027dd95eb 100644
--- a/dom/system/nsDeviceSensors.cpp
+++ b/dom/system/nsDeviceSensors.cpp
@@ -472,9 +472,6 @@ nsDeviceSensors::FireDOMOrientationEvent(EventTarget* aTarget,
   static bool sIsDispatchingRelativeEvents = false;
   sIsDispatchingRelativeEvents = sIsDispatchingRelativeEvents || !aIsAbsolute;
 
-  // Android devices with SENSOR_GAME_ROTATION_VECTOR support dispatch
-  // relative events for "deviceorientation" by default, while other platforms
-  // and devices without such support dispatch absolute events by default.
   if (aIsAbsolute && !sIsDispatchingRelativeEvents) {
     // For absolute events on devices without support for relative events,
     // we need to additionally dispatch type "deviceorientation" to keep
diff --git a/layout/base/nsFrameManagerBase.h b/layout/base/nsFrameManagerBase.h
index bb192b64f..d935d97f6 100644
--- a/layout/base/nsFrameManagerBase.h
+++ b/layout/base/nsFrameManagerBase.h
@@ -58,13 +58,14 @@ protected:
   bool                            mIsDestroyingFrames;  // The frame manager is destroying some frame(s).
 
   // The frame tree generation number
-  // We use this to avoid unnecessary screenshotting
-  // on Android. Unfortunately, this is static to match
+  // Unfortunately, this is static to match
   // the single consumer which is also static. Keeping
   // this the same greatly simplifies lifetime issues and
   // makes sure we always using the correct number.
   // A per PresContext generation number is available
   // via nsPresContext::GetDOMGeneration
+  // XXXMC: This was introduced for issues on Android. Can potentially
+  // be removed.
   static uint32_t                 sGlobalGenerationNumber;
 };
 
diff --git a/mozglue/build/arm.cpp b/mozglue/build/arm.cpp
index e11985e4d..a2f40246d 100644
--- a/mozglue/build/arm.cpp
+++ b/mozglue/build/arm.cpp
@@ -32,11 +32,9 @@ get_arm_cpu_flags(void)
   FILE     *fin;
   bool      armv6_processor = false;
   flags = 0;
-  /*Reading /proc/self/auxv would be easier, but that doesn't work reliably on
-    Android. This also means that detection will fail in Scratchbox, which is
-    desirable, as NEON does not work in the qemu shipped with the Maemo 5 SDK.
-    I don't know if /proc/self/auxv would do any better in that case, anyway,
-    or if it would return random flags from the host CPU.*/
+  /*Reading /proc/self/auxv would be easier, but that doesn't work reliably in
+    qemu and potentially other virtual environments.
+    It might also return random flags from the host CPU in that case.*/
   fin = fopen ("/proc/cpuinfo","r");
   if (fin != nullptr)
   {
diff --git a/mozglue/misc/StackWalk.cpp b/mozglue/misc/StackWalk.cpp
index 8b50ddc34..0fa2250ae 100644
--- a/mozglue/misc/StackWalk.cpp
+++ b/mozglue/misc/StackWalk.cpp
@@ -831,7 +831,7 @@ unwind_callback(struct _Unwind_Context* context, void* closure)
     info->isCriticalAbort = true;
     // We just want to stop the walk, so any error code will do.  Using
     // _URC_NORMAL_STOP would probably be the most accurate, but it is not
-    // defined on Android for ARM.
+    // defined on all OSes for ARM.
     return _URC_FOREIGN_EXCEPTION_CAUGHT;
   }
   if (--info->skip < 0) {
@@ -864,10 +864,7 @@ MozStackWalk(MozWalkStackCallback aCallback, uint32_t aSkipFrames,
   (void)_Unwind_Backtrace(unwind_callback, &info);
 
   // We ignore the return value from _Unwind_Backtrace and instead determine
-  // the outcome from |info|.  There are two main reasons for this:
-  // - On ARM/Android bionic's _Unwind_Backtrace usually (always?) returns
-  //   _URC_FAILURE.  See
-  //   https://bugzilla.mozilla.org/show_bug.cgi?id=717853#c110.
+  // the outcome from |info|.  The main reason for this:
   // - If aMaxFrames != 0, we want to stop early, and the only way to do that
   //   is to make unwind_callback return something other than _URC_NO_REASON,
   //   which causes _Unwind_Backtrace to return a non-success code.
diff --git a/security/manager/ssl/nsNSSComponent.cpp b/security/manager/ssl/nsNSSComponent.cpp
index b9f8b6e21..7880959c9 100644
--- a/security/manager/ssl/nsNSSComponent.cpp
+++ b/security/manager/ssl/nsNSSComponent.cpp
@@ -1128,13 +1128,9 @@ nsNSSComponent::LoadLoadableRoots()
   nsAutoString modName;
   nsresult rv = GetPIPNSSBundleString("RootCertModuleName", modName);
   if (NS_FAILED(rv)) {
-    // When running Cpp unit tests on Android, this will fail because string
-    // bundles aren't available (see bug 1311077, bug 1228175 comment 12, and
-    // bug 929655). Because the module name is really only for display purposes,
-    // we can just hard-code the value here. Furthermore, if we want to be able
-    // to stop using string bundles in PSM in this way, we'll have to hard-code
-    // the string and only use the localized version when displaying it to the
-    // user, so this is a step in that direction anyway.
+    // If we want to be able to stop using string bundles in PSM, we'll have to
+    // hard-code the string and only use the localized version when displaying
+    // it to the user, so this is a step in that direction anyway.
     modName.AssignLiteral("Builtin Roots Module");
   }
 
diff --git a/widget/IMEData.h b/widget/IMEData.h
index 04245df26..ff458e447 100644
--- a/widget/IMEData.h
+++ b/widget/IMEData.h
@@ -296,8 +296,7 @@ struct InputContext final
   Origin mOrigin;
 
   /* True if the webapp may be unaware of IME events such as input event or
-   * composiion events. This enables a key-events-only mode on Android for
-   * compatibility with webapps relying on key listeners. */
+   * composiion events. */
   bool mMayBeIMEUnaware;
 
   /* Whether the owning document of the input element has been loaded
@@ -405,7 +404,7 @@ struct InputContextAction final
 
 // IMEMessage is shared by IMEStateManager and TextComposition.
 // Update values in GeckoEditable.java if you make changes here.
-// XXX Negative values are used in Android...
+// int instead of uint in case OSes use negative values internally.
 typedef int8_t IMEMessageType;
 enum IMEMessage : IMEMessageType
 {
diff --git a/xpcom/base/nsCycleCollector.cpp b/xpcom/base/nsCycleCollector.cpp
index 9acc2d7b7..8df3c3a6b 100644
--- a/xpcom/base/nsCycleCollector.cpp
+++ b/xpcom/base/nsCycleCollector.cpp
@@ -1609,10 +1609,7 @@ private:
                             &logFile);
     }
 
-    // On Android or B2G, this function will open a file named
-    // aFilename under a memory-reporting-specific folder
-    // (/data/local/tmp/memory-reports). Otherwise, it will open a
-    // file named aFilename under "NS_OS_TEMP_DIR".
+    // This function will open a file named aFilename under "NS_OS_TEMP_DIR".
     nsresult rv = nsDumpUtils::OpenTempFile(filename, &logFile,
                                             NS_LITERAL_CSTRING("memory-reports"));
     if (NS_FAILED(rv)) {
diff --git a/xpcom/glue/nsDebug.h b/xpcom/glue/nsDebug.h
index 2feaba94e..8921d6021 100644
--- a/xpcom/glue/nsDebug.h
+++ b/xpcom/glue/nsDebug.h
@@ -390,10 +390,6 @@ extern "C" {
 /**
  * printf_stderr(...) is much like fprintf(stderr, ...), except that:
  *  - it calls the callback set through set_stderr_callback
- *  - on Android and Firefox OS, *instead* of printing to stderr, it
- *    prints to logcat.  (Newlines in the string lead to multiple lines
- *    of logcat, but each function call implicitly completes a line even
- *    if the string does not end with a newline.)
  *  - on Windows, if a debugger is present, it calls OutputDebugString
  *    in *addition* to writing to stderr
  */
@@ -407,17 +403,6 @@ void vprintf_stderr(const char* aFmt, va_list aArgs);
 /**
  * fprintf_stderr is like fprintf, except that if its file argument
  * is stderr, it invokes printf_stderr instead.
- *
- * This is useful for general debugging code that logs information to a
- * file, but that you would like to be useful on Android and Firefox OS.
- * If you use fprintf_stderr instead of fprintf in such debugging code,
- * then callers can pass stderr to get logging that works on Android and
- * Firefox OS (and also the other side-effects of using printf_stderr).
- *
- * Code that is structured this way needs to be careful not to split a
- * line of output across multiple calls to fprintf_stderr, since doing
- * so will cause it to appear in multiple lines in logcat output.
- * (Producing multiple lines at once is fine.)
  */
 void fprintf_stderr(FILE* aFile, const char* aFmt, ...) MOZ_FORMAT_PRINTF(2, 3);
 
diff --git a/xpcom/system/nsIDeviceSensors.idl b/xpcom/system/nsIDeviceSensors.idl
index dcb67cb92..8ee559f07 100644
--- a/xpcom/system/nsIDeviceSensors.idl
+++ b/xpcom/system/nsIDeviceSensors.idl
@@ -11,12 +11,9 @@ interface nsIDeviceSensorData : nsISupports
 {
   // Keep in sync with hal/HalSensor.h
 
-  // 1. TYPE_ORIENTATION: absolute device orientation, not spec-conform and
-  // deprecated on Android.
+  // 1. TYPE_ORIENTATION: absolute device orientation, not spec-conform.
   // 2. TYPE_ROTATION_VECTOR: absolute device orientation affected by drift.
   // 3. TYPE_GAME_ROTATION_VECTOR: relative device orientation less affected by drift.
-  // Preferred fallback priorities on Android are [3, 2, 1] for the general case
-  // and [2, 1] if absolute orientation (compass heading) is required.
   const unsigned long TYPE_ORIENTATION = 0;
   const unsigned long TYPE_ACCELERATION = 1;
   const unsigned long TYPE_PROXIMITY = 2;
diff --git a/xpcom/threads/BackgroundHangMonitor.h b/xpcom/threads/BackgroundHangMonitor.h
index c323cd7cf..93db01a4d 100644
--- a/xpcom/threads/BackgroundHangMonitor.h
+++ b/xpcom/threads/BackgroundHangMonitor.h
@@ -40,7 +40,7 @@ class BackgroundHangManager;
  * running time. This is a good starting point for determining the timeout
  * and maximum timeout values. For example, the Compositor thread has a
  * responsiveness goal of 60Hz or 17ms, so a starting timeout could be
- * 100ms. Considering some platforms (e.g. Android) can terminate the app
+ * 100ms. Considering some platforms can terminate the application
  * when a critical thread hangs for longer than a few seconds, a good
  * starting maximum timeout is 4 or 5 seconds.
  *