diff options
| -rw-r--r-- | build/docs/androideclipse.rst | 90 | ||||
| -rw-r--r-- | build/docs/cppeclipse.rst | 8 | ||||
| -rw-r--r-- | build/docs/index.rst | 1 | ||||
| -rw-r--r-- | build/docs/locales.rst | 79 | ||||
| -rw-r--r-- | build/docs/mozinfo.rst | 9 | ||||
| -rw-r--r-- | build/docs/toolchains.rst | 55 | ||||
| -rw-r--r-- | build/moz-automation.mk | 2 | ||||
| -rw-r--r-- | dom/plugins/base/nsNPAPIPluginInstance.cpp | 3 | ||||
| -rw-r--r-- | dom/system/nsDeviceSensors.cpp | 3 | ||||
| -rw-r--r-- | layout/base/nsFrameManagerBase.h | 5 | ||||
| -rw-r--r-- | mozglue/build/arm.cpp | 8 | ||||
| -rw-r--r-- | mozglue/misc/StackWalk.cpp | 7 | ||||
| -rw-r--r-- | security/manager/ssl/nsNSSComponent.cpp | 10 | ||||
| -rw-r--r-- | widget/IMEData.h | 5 | ||||
| -rw-r--r-- | xpcom/base/nsCycleCollector.cpp | 5 | ||||
| -rw-r--r-- | xpcom/glue/nsDebug.h | 15 | ||||
| -rw-r--r-- | xpcom/system/nsIDeviceSensors.idl | 5 | ||||
| -rw-r--r-- | xpcom/threads/BackgroundHangMonitor.h | 2 |
18 files changed, 26 insertions, 286 deletions
diff --git a/build/docs/androideclipse.rst b/build/docs/androideclipse.rst deleted file mode 100644 index a8c048130d..0000000000 --- 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 4492add473..3596a2f9a6 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 63e0537575..75000aff33 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 4705ed9634..86c740218e 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 85ceb66576..758d4862fd 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 eba640fa06..6ad460a1e2 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 e7fa16fcb7..971bdddf93 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 203c61a5c8..6e35bf3662 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 3b6babc67c..027dd95eb6 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 bb192b64f4..d935d97f6a 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 e11985e4d7..a2f40246df 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 8b50ddc347..0fa2250aec 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 b9f8b6e21d..7880959c9f 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 04245df269..ff458e447d 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 9acc2d7b7e..8df3c3a6bc 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 2feaba94e1..8921d60214 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 dcb67cb925..8ee559f07f 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 c323cd7cf3..93db01a4d7 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. * |