Improve hitrate for ClonedSecureRandomTest

The test case testCheckForDuplicateOutput attempts to first create a
map of sequences of random numbers from the SecureRandomService
together with their pid during that run.

Generally, these pids span about 4000 pids, with a gap of about 20-30
between each pid in the map.

It then tries to waste enough pids to make the pid numbering loop
around in an attempt to make a new instance of the SecureRandomService
with a pid already seen.

However, since the map is so sparse, the chance of actually hitting a
pid that has been seen previously is small, even in the correct span.
Therefore, many pids need to be tested.

Wasting enough pids to make it overflow takes a long time, so to make
the test run time effective (and not trigger the ten minute timeout) a
large number of pids need to be tested before running wastePids again.

The current wastePids method tries to prevent running if it tries to
run when the current pid is less than 2048 from the first pid. However,
since the wastePids method doesn't do anything to account for any pids
already taken, it generally misses by at least 1400 pids, often more,
especially if there are more background processes with extra threads
taking up pids.

This means that the majority of the map (the ones who have pids more
than 2048 than the first pid) are not checked, and of these, a majority
(1400+ on nexus phones) are not checked since they are skipped over by
the wastePids function. With any kind of extra processes running, this
small gap can easily shrink, even to 0, meaning only a single pid gets
tested between wasting pids to overflow. This means that the test is
extremely time ineffective and highly likely to time out, resulting in
false failures.

Making sure that wastePids is not run before all pids from where
wastePids ends up to the last pid in the map vastly increases the
hitrate, making the test run a lot faster, and makes it more likely
to pass even on phones with more background threads are present.

If needed, improvements to the wastePids function to attempt to not
over-waste as much would also help this, but that would be more
complex, so may not be worth it unless more problems become apparent.

Change-Id: I3221c1c7bbb991b8c5d580a1c146927aaebd811f
diff --git a/tests/tests/security/src/android/security/cts/ClonedSecureRandomTest.java b/tests/tests/security/src/android/security/cts/ClonedSecureRandomTest.java
index 8ebe6ac..dfefad7 100644
--- a/tests/tests/security/src/android/security/cts/ClonedSecureRandomTest.java
+++ b/tests/tests/security/src/android/security/cts/ClonedSecureRandomTest.java
@@ -120,6 +120,7 @@
          */
         int firstPid = -1;
         int previousPid = -1;
+        int lastPid = -1;
         for (int i = 0; i < MAX_PID; i++) {
             byte[] output = new byte[RANDOM_BYTES_PER_PID];
             int pid;
@@ -202,7 +203,9 @@
                 firstPid = pid;
             }
 
-            if (i > PRIMING_ITERATIONS) {
+            if (i <= PRIMING_ITERATIONS) {
+                lastPid = pid;
+            } else if (pid > lastPid && (lastPid > firstPid || pid < firstPid)) {
                 wastePids(firstPid, previousPid);
             }
         }