Fix issue #38210653: Few more tweaks of job scheduler

- Now keep track of the time a job was enqueued, and order
  the pending list by that.
- Added configuration constants for rescheduling: maximum
  times to reschedule, minimum backoff times.
- Fixed printing of active jobs -- the method to get the current
  JobStatus was old and didn't require the caller to hold a
  lock, so made a copy, which didn't contain all the data we were
  interested in.  Now with our simple locking, we can just make
  that require the caller hold a lock and return the real
  JobStatus object.
- Include oom_adj and procstate when printing information about
  processes being killed.
- Expanded documentation of BroadcastReceiver.goAsync().

Test: bit CtsJobSchedulerTestCases:*

Change-Id: I2e45f181e45be9836c74cbff1b844ffdf6e93019

core/java/android/app/job/JobInfo.java

@@ -111,8 +111,11 @@ public class JobInfo implements Parcelable {
     /* Minimum flex for a periodic job, in milliseconds. */
     private static final long MIN_FLEX_MILLIS = 5 * 60 * 1000L; // 5 minutes
 
-    /* Minimum backoff interval for a job, in milliseconds */
-    private static final long MIN_BACKOFF_MILLIS = 10 * 1000L;      // 10 seconds
+    /**
+     * Minimum backoff interval for a job, in milliseconds
+     * @hide
+     */
+    public static final long MIN_BACKOFF_MILLIS = 10 * 1000L;      // 10 seconds
 
     /**
      * Query the minimum interval allowed for periodic scheduled jobs.  Attempting
@@ -431,7 +434,7 @@ public class JobInfo implements Parcelable {
     /**
      * The amount of time the JobScheduler will wait before rescheduling a failed job. This value
      * will be increased depending on the backoff policy specified at job creation time. Defaults
-     * to 5 seconds.
+     * to 30 seconds, minimum is currently 10 seconds.
      */
     public long getInitialBackoffMillis() {
         final long minBackoff = getMinBackoffMillis();

core/java/android/content/BroadcastReceiver.java

@@ -330,10 +330,32 @@ public abstract class BroadcastReceiver {
      * This can be called by an application in {@link #onReceive} to allow
      * it to keep the broadcast active after returning from that function.
      * This does <em>not</em> change the expectation of being relatively
-     * responsive to the broadcast (finishing it within 10s), but does allow
+     * responsive to the broadcast, but does allow
      * the implementation to move work related to it over to another thread
      * to avoid glitching the main UI thread due to disk IO.
      *
+     * <p>As a general rule, broadcast receivers are allowed to run for up to 10 seconds
+     * before they system will consider them non-responsive and ANR the app.  Since these usually
+     * execute on the app's main thread, they are already bound by the ~5 second time limit
+     * of various operations that can happen there (not to mention just avoiding UI jank), so
+     * the receive limit is generally not of concern.  However, once you use {@goAsync}, though
+     * able to be off the main thread, the broadcast execution limit still applies, and that
+     * includes the time spent between calling this method and ultimately
+     * {@link PendingResult#finish() PendingResult.finish()}.</p>
+     *
+     * <p>If you are taking advantage of this method to have more time to execute, it is useful
+     * to know that the available time can be longer in certain situations.  In particular, if
+     * the broadcast you are receiving is not a foreground broadcast (that is, the sender has not
+     * used {@link Intent#FLAG_RECEIVER_FOREGROUND}), then more time is allowed for the receivers
+     * to run, allowing them to execute for 30 seconds or even a bit more.  This is something that
+     * receivers should rarely take advantage of (long work should be punted to another system
+     * facility such as {@link android.app.job.JobScheduler}, {@link android.app.Service}, or
+     * see especially {@link android.support.v4.app.JobIntentService}), but can be useful in
+     * certain rare cases where it is necessary to do some work as soon as the broadcast is
+     * delivered.  Keep in mind that the work you do here will block further broadcasts until
+     * it completes, so taking advantage of this at all excessively can be counter-productive
+     * and cause later events to be received more slowly.</p>
+     *
      * @return Returns a {@link PendingResult} representing the result of
      * the active broadcast.  The BroadcastRecord itself is no longer active;
      * all data and other interaction must go through {@link PendingResult}