)]}'
{
  "log": [
    {
      "commit": "2da3cbb4af20a64108e474c0bbbe0cc5d3af2aa2",
      "tree": "8cbdf50aab2183c701f1dc7c9ac17d1129fb5238",
      "parents": [
        "0518af4e87d484b10e785aff9b030b688926cd7f"
      ],
      "author": {
        "name": "David Brazdil",
        "email": "dbrazdil@google.com",
        "time": "Wed Jan 30 16:17:50 2019 +0000"
      },
      "committer": {
        "name": "David Brazdil",
        "email": "dbrazdil@google.com",
        "time": "Fri Feb 01 14:59:57 2019 +0000"
      },
      "message": "hiddenapi: Fix class hierarchy traversal\n\n`hiddenapi` builds and traverses the class hierarchy, visiting all\nclass members that methods/fields in stubs may resolve to.\n\nThe algorithm wouldn\u0027t work when:\n* an interface declares a method which is in stubs, and\n* a class implements the interface by inheriting the method from its\n  superclass; neither the class nor its superclass are in stubs.\nThe problem was that once a matching method was found, only subclasses\nwould be traversed. In this case, the method would be found in the\ninterface, the class which implements it would be traversed but its\nsuperclass would not.\n\nThis patch simplifies the algorithm and partially reverts a performance\noptimization which caused the problem. As a result, there is a build\ntime regression from 5s to 8s.\n\nThe patch also adds gtests which test this behaviour. There were no\ntests until now because stubs are not present in master-art manifest.\nGet around this issue by using the actual core JARs as stubs but test\nthe behaviour on other classes.\n\nBug: 122551864\nTest: m test-art-host-gtest-hiddenapi_test\nChange-Id: I63751c5ef517c8e9d3a157dfbec8de01bd99c2d4\n"
    },
    {
      "commit": "2b9c35be35a759ba2032692648f5bbcb1e7e78c8",
      "tree": "4825fdb4a4ecd27922dc9c945b30423534e67010",
      "parents": [
        "6d4c343ee5db18f039aeb3e07ff8d3c1fd37c3a0"
      ],
      "author": {
        "name": "David Brazdil",
        "email": "dbrazdil@google.com",
        "time": "Fri Jan 12 15:44:43 2018 +0000"
      },
      "committer": {
        "name": "David Brazdil",
        "email": "dbrazdil@google.com",
        "time": "Tue Jan 16 15:32:12 2018 +0000"
      },
      "message": "Introduce new build tool: hiddenapi\n\nNew tool `hiddenapi` iterates over all class members inside given\nDEX files and modifies their access flags if their signatures\nappear on one of two lists - greylist and blacklist - provided as\ntext file inputs. These access flags denote to the runtime that\nthe marked methods/fields should be treated as internal APIs with\nrestricted access.\n\nTwo bits of information are encoded in the DEX access flags. These\nare encoded as unsigned LEB128 values in DEX and so as to not\nincrease the size of the DEX, different modifiers were chosen to\ncarry the information under different circumstances.\n\nFirst bit is encoded as the inversion of visibility access flags\n(bits 2:0). At most one of these flags can be set at any given time.\nInverting these bits therefore produces a value where at least two\nbits are set and there is never any loss of information.\n\nSecond bit is encoded differently for each given type of class\nmember as there is no single unused bit such that setting it would\nnot increase the size of the LEB128 encoding.\n - Bit 5 for fields as it carries no other meaning\n - Bit 5 for non-native methods, as `synchronized` can only be set\n   on native methods\n - Bit 9 for native methods, as it carries no meaning and bit 8\n   (native) will make the LEB128 encoding at least two bytes long\n\nThis tool is meant to be applied on boot class path DEX files and\nas such, this encoding is not part of the DEX specification and may\nchange in the future. Access flags returned by ClassDataItemIterator\nare stripped of these hidden flags and thus fully transparent to the\nruntime.\n\nTest: m test-art-host\nBug: 64382372\nChange-Id: Ifc237ff8a35a8b470b7fc682a9cb879370d1e6e9\n"
    }
  ]
}