1. 11 Jul, 2016 3 commits
  2. 21 Jun, 2016 2 commits
  3. 20 Jun, 2016 13 commits
  4. 13 Jun, 2016 1 commit
  5. 07 Jun, 2016 2 commits
  6. 06 Jun, 2016 1 commit
  7. 25 May, 2016 2 commits
  8. 23 May, 2016 3 commits
  9. 19 May, 2016 1 commit
    • Henrik Engström's avatar
      Improve hitrate for ClonedSecureRandomTest · c97737ce
      Henrik Engström authored
      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
      c97737ce
  10. 12 May, 2016 4 commits
  11. 11 May, 2016 1 commit
  12. 05 May, 2016 4 commits
  13. 29 Apr, 2016 1 commit
  14. 28 Apr, 2016 2 commits