)]}'
{
  "log": [
    {
      "commit": "cc4f7db698f88b633a286d8ab1105b28a474cd09",
      "tree": "02ec7d914ab182e912af5c147ebc7483a719c6de",
      "parents": [
        "ad4d2c99ed3a08a5090c38e9dd906df8fb894614"
      ],
      "author": {
        "name": "Jeff Brown",
        "email": "jeffbrown@google.com",
        "time": "Tue Aug 30 20:34:48 2011 -0700"
      },
      "committer": {
        "name": "Jeff Brown",
        "email": "jeffbrown@google.com",
        "time": "Tue Aug 30 21:40:28 2011 -0700"
      },
      "message": "Fix input channel leak.\nBug: 5156144\n\nInput channels could leak or simply live longer than they should\nin some cases.\n\n1. Monitor channels (used by the pointer location overlay) are never\n   unregistered, so they would leak.\n\n   Added code to handle failures in the receive callback by closing\n   the input channel.\n\n2. The DragState held onto its input window and application handles\n   even after the input channel was disposed.\n\n   Added code to null these handles out when they are no longer needed.\n\n3. Input channels previously used as input event targets would stick\n   around until the targets were cleared (usually on the next\n   event).\n\n   Added code to detect when the input dispatcher is in\n   an idle state and to proactively clear the targets then\n   to ensure that resources are released promptly.\n\n4. Native input window handles held onto the input channel even\n   after the input window was removed from the input dispatcher.\n   Consequently, the input channel would not be disposed until\n   the input window handle itself was freed.  Since the input\n   window handle is held from managed code, this meant that the\n   window\u0027s input channel could stick around until the next GC.\n\n   Refactored the input window handle to separate the properties\n   (info) and identify (handle) state into different objects.\n   Then modified the dispatcher to release the properties (info)\n   when no longer needed, including the input channel.\n\n7. The pointer location overlay does not actually use its\n   standard input channel, only the monitor input channel.\n\n   Added INPUT_FEATURE_NO_INPUT_CHANNEL to allow windows to\n   request that they not be provided with an input channel\n   at all.\n\nImproved some of the error handling logic to emit the status\ncode as part of the exception message.\n\nChange-Id: I01988d4391a70c6678c8b0e936ca051af680b1a5\n"
    },
    {
      "commit": "9302c8796fc4dcda08d4bd1e11733848fd4fafaf",
      "tree": "1008e3db6ba1eb6ee02b7bf8c4a648a13a0b741d",
      "parents": [
        "14fcf900ce65e5c8c952c95ee12041f8de16fbb7"
      ],
      "author": {
        "name": "Jeff Brown",
        "email": "jeffbrown@google.com",
        "time": "Wed Jul 13 22:51:29 2011 -0700"
      },
      "committer": {
        "name": "Jeff Brown",
        "email": "jeffbrown@google.com",
        "time": "Thu Jul 14 04:11:21 2011 -0700"
      },
      "message": "Refactor input dispatcher use of window/app handles.\n\nThis change moves the cached window and application input state\ninto the handle objects themselves.  It simplifies the dispatcher\nsomewhat because it no longer needs to fix up references to\ntransient InputWindow objects each time the window list is updated.\n\nThis change will also make it easier to optimize setInputWindows\nto avoid doing a lot of redundant data copying.  In principle, only\nthe modified fields need to be updated.  However, for now we\ncontinue to update all fields in unison as before.\n\nIt turns out that the input dispatcher was inappropriately retaining\npointers to InputWindow objects within the mWindows InputWindow\nvector.  This vector is copy-on-write so it is possible and the\nitem pointers to change if an editing operation is performed on\nthe vector when it does not exclusively own the underlying\nSharedBuffer.  This bug was uncovered by a previous change that\nreplaced calls to clear() and appendVector() with a simple use\nof operator\u003d which caused the buffer to be shared.  Consequently\nafter editItemAt was called (which it shouldn\u0027t have, actually)\nthe buffer was copied and the cached InputWindow pointers became\ninvalid.  Oops.  This change fixes the problem.\n\nChange-Id: I0a259339a6015fcf9113dc4081a6875e047fd425\n"
    },
    {
      "commit": "4fb76253f255f0adb8a64835af37bb9176ee4016",
      "tree": "2585ba2501180f9b02a0ab6bc45a4df668ae4bbc",
      "parents": [
        "0ed2e845db3f6bc7bc12a08ada18363942c2fb3d"
      ],
      "author": {
        "name": "Jeff Brown",
        "email": "jeffbrown@android.com",
        "time": "Fri May 13 12:51:12 2011 -0700"
      },
      "committer": {
        "name": "Jeff Brown",
        "email": "jeffbrown@android.com",
        "time": "Fri May 13 12:51:12 2011 -0700"
      },
      "message": "Fix bounds check.\nBug: 4413945\n\nAlso remove dead code from header file.\n\nChange-Id: I4e9fc9d7f8612fedb436e62649d308bd737ed138\n"
    },
    {
      "commit": "e2515eebf42c763c0a2d9f873a153711778cfc17",
      "tree": "ee159940f05c439d0524771bfbfe6b551c82c2d4",
      "parents": [
        "158e3582c03ab9e0221718da20fc8854bb9216d0"
      ],
      "author": {
        "name": "Dianne Hackborn",
        "email": "hackbod@google.com",
        "time": "Wed Apr 27 18:52:56 2011 -0400"
      },
      "committer": {
        "name": "Dianne Hackborn",
        "email": "hackbod@google.com",
        "time": "Mon May 09 17:03:24 2011 -0700"
      },
      "message": "Better compat mode part one: start scaling windows.\n\nFirst step of improving app screen size compatibility mode.  When\nrunning in compat mode, an application\u0027s windows are scaled up on\nthe screen rather than being small with 1:1 pixels.\n\nCurrently we scale the application to fill the entire screen, so\ndon\u0027t use an even pixel scaling.  Though this may have some\nnegative impact on the appearance (it looks okay to me), it has a\nbig benefit of allowing us to now treat these apps as normal\nfull-screens apps and do the normal transition animations as you\nmove in and out and around in them.\n\nThis introduces fun stuff in the input system to take care of\nmodifying pointer coordinates to account for the app window\nsurface scaling.  The input dispatcher is told about the scale\nthat is being applied to each window and, when there is one,\nadjusts pointer events appropriately as they are being sent\nto the transport.\n\nAlso modified is CompatibilityInfo, which has been greatly\nsimplified to not be so insane and incomprehendible.  It is\nnow simple -- when constructed it determines if the given app\nis compatible with the current screen size and density, and\nthat is that.\n\nThere are new APIs on ActivityManagerService to put applications\nthat we would traditionally consider compatible with larger screens\nin compatibility mode.  This is the start of a facility to have\na UI affordance for a user to switch apps in and out of\ncompatibility.\n\nTo test switching of modes, there is a new variation of the \"am\"\ncommand to do this: am screen-compat [on|off] [package]\n\nThis mode switching has the fundamentals of restarting activities\nwhen it is changed, though the state still needs to be persisted\nand the overall mode switch cleaned up.\n\nFor the few small apps I have tested, things mostly seem to be\nworking well.  I know of one problem with the text selection\nhandles being drawn at the wrong position because at some point\nthe window offset is being scaled incorrectly.  There are\nprobably other similar issues around the interaction between\ntwo windows because the different window coordinate spaces are\ndone in a hacky way instead of being formally integrated into\nthe window manager layout process.\n\nChange-Id: Ie038e3746b448135117bd860859d74e360938557\n"
    },
    {
      "commit": "fbf097732137a32930d151f7ba6816a5b870c32a",
      "tree": "1f05823ea1cb06aaa3ab0954cdde614b370f30e6",
      "parents": [
        "115ad16551c9cf9551f44cbea59f3edf83e4a340"
      ],
      "author": {
        "name": "Jeff Brown",
        "email": "jeffbrown@google.com",
        "time": "Sun Jan 16 14:06:57 2011 -0800"
      },
      "committer": {
        "name": "Jeff Brown",
        "email": "jeffbrown@google.com",
        "time": "Sun Jan 16 18:58:49 2011 -0800"
      },
      "message": "Support non-rectangular input regions.\n\nThis enables the system bar to carve out a region through which\nevents will be sent to the IME behind it.\n\nBug: 3238092\nChange-Id: I69b855a8d9b5b3ee525266c0861826e53e5b5028\n"
    },
    {
      "commit": "928e054931d357326613c78e62f4d850b7c442ff",
      "tree": "28367a3b3d9b11f31a97c9016ab64e22f05c4c47",
      "parents": [
        "b3fbd7e0fd44a72fb7ccba0959481b8a806608b7"
      ],
      "author": {
        "name": "Jeff Brown",
        "email": "jeffbrown@google.com",
        "time": "Mon Jan 10 11:17:36 2011 -0800"
      },
      "committer": {
        "name": "Jeff Brown",
        "email": "jeffbrown@google.com",
        "time": "Mon Jan 10 17:23:05 2011 -0800"
      },
      "message": "Prevent events from getting backlogged.\n\nThis change implements two heuristics.\n\n1. When events are older than 10 seconds, they are dropped.\n\n2. If the application is currently busy processing an event and\n   the user touches a window belonging to a different application\n   then we drop the currently queued events so the other application\n   can start processing the gesture immediately.\n\nNote that the system takes care of synthesizing cancelation events\nautomatically for any events that it drops.\n\nAdded some new handle types to allow the native dispatcher to\nindirectly refer to the WindowManager\u0027s window state and app window\ntoken.  This was done to enable the dispatcher to identify the\napplication to which each window belongs but it also eliminates\nsome lookup tables and linear searches through the window list\non each key press.\n\nBug: 3224911\nChange-Id: I9dae8dfe23d195d76865f97011fe2f1d351e2940\n"
    }
  ]
}