)]}'
{
  "log": [
    {
      "commit": "c81a8493884c7f432d6bd5b98aca3fbdc93b355b",
      "tree": "7980d444f02c96c4ca1333efb7fdac400a5f523f",
      "parents": [
        "f33468e68a6e78c6a2c88d90de4fbce55cad7eac"
      ],
      "author": {
        "name": "Chet Haase",
        "email": "chet@google.com",
        "time": "Fri Jul 12 12:54:38 2013 -0700"
      },
      "committer": {
        "name": "Chet Haase",
        "email": "chet@google.com",
        "time": "Fri Jul 12 13:40:38 2013 -0700"
      },
      "message": "Fix minor transition bugs and add capabilities\n\nSome view changes require more flexible transitions than the\ndefaults provided by Crossfade and TextChange - this change supplies some\nof that flexibility.\n\nAlso, starting a new transition on a hierarchy undergoing a transition\ncaused the first to get canceled, then the start values to be retrieved.\nThe new transition should actually get the start values from the intermediate\nstate of the views, so we now cancel the previous transition only after the\nstart values have been captured.\n\nIssue #9756349 Transitions: Crossfade does not handle interruption/reverse correctly\nIssue #9295863 Transitions: Add behavior API/flags to various transitions\nIssue #9275859 Transitions: Improve mechanism for transition interruption\n\nChange-Id: I5a8c5a12466ddcab9e84e4880930563fa1216f3b\n"
    },
    {
      "commit": "dc57d9dda559aaf06237b9124dc9ef27513bab31",
      "tree": "887177b3a22c8e087637a04daefa7cec6b83179a",
      "parents": [
        "0d21c220ddb1873133c24449404f82c28b19b8b4"
      ],
      "author": {
        "name": "Chet Haase",
        "email": "chet@google.com",
        "time": "Wed Jul 10 11:27:54 2013 -0700"
      },
      "committer": {
        "name": "Chet Haase",
        "email": "chet@google.com",
        "time": "Wed Jul 10 12:14:54 2013 -0700"
      },
      "message": "Fix minor transition bugs\n\nTransitionGroup.setDuration() was not propagating the new duration to\nfuture child transitions correctly.\n\nAlso, Fade should restore a fully-opaque value when a transition ends, to prevent\nthe problem of mid-stream canceled transitions causing vie3ws to get stuck with partially\nfaded-in alpha values.\n\nIssue #9755995 Transitions: TransitionGroup.setDuration() not handled correctly\nIssue #9756655 Transitions: handle fading cancelation better\n\nChange-Id: Id44569c6f4152a26ee382d04c30a2f035a1ebcf3\n"
    },
    {
      "commit": "2ea7f8b9c5f903050d42c1af57406bf528979f45",
      "tree": "80f0c3fcb68c1842f28906a306e3b41468b2fef0",
      "parents": [
        "862a301bf9fd3d315948872873602ba7bcb043d4"
      ],
      "author": {
        "name": "Chet Haase",
        "email": "chet@google.com",
        "time": "Fri Jun 21 15:00:05 2013 -0700"
      },
      "committer": {
        "name": "Chet Haase",
        "email": "chet@google.com",
        "time": "Fri Jun 21 16:07:14 2013 -0700"
      },
      "message": "Refactoring/simplifying Transition code/API\n\nTransitions used to be three phase:\n- captureValues(): get all relevant property values in the\naffected view targets\n- setup(): set appropriate start values for affected views\nprior to any transitions being played\n- play(): create/play Animators for affected views\n\nNow the second and third phases have been collapsed (and named\n\"play()\"). This single step sets initial values for target views\nand creates any Animators that should be played during the transition.\nThe transition mechanism stores these Animators and then starts\nthem at the appropriate time in the overall transition.\n\nIssue #9507585 Transitions: Simplify Transition.play() design\n\nChange-Id: I3fc67599b38fe49eee885dc5d32444db90b7703b\n"
    },
    {
      "commit": "6ebe3de331efd00ba23bc4191d4a82cfa4c39160",
      "tree": "8899ae2504fddbfbdaba69f85bc37f11e65ab022",
      "parents": [
        "cb64e3e6d33228221a3730e03292b2c1b2b8649b"
      ],
      "author": {
        "name": "Chet Haase",
        "email": "chet@google.com",
        "time": "Mon Jun 17 16:50:50 2013 -0700"
      },
      "committer": {
        "name": "Chet Haase",
        "email": "chet@google.com",
        "time": "Thu Jun 20 15:35:04 2013 -0700"
      },
      "message": "Fix transitions on disappearing view hiearchies\n\nPreviously, Fade transitions did not work correctly on hirearchies; they\nonly handled individual views. in particular, they would side-effect all\nfading views by removing them from their parent to fade them out in the\noverlay of the scene root. This worked for the fade-out transition itself,\nbut caused problems when those same hierarchies were added back in and\nanother Fade was run on the hierarchy, because now all of the views inside\nthat parent node had been removed, so they didn\u0027t fade in at all.\n\nThe fix was to add logic in Visibility to detect when a disappearing\nview was inside a hierarchy that was also disappearing, and to skip the\nfade on the views inside that hierarchy, leaving only the top-most\ndisappearing view to be faded out, thus preserving the hierarchy under\nthat faded-out group.\n\nAlong the way, there were various cleanups, fixes, and refactorings in the\ntransition code, and slight API modifications.\n\nIssue #9406371 Transitions: Removing view hierarchy not working correctly\nIssue #9470255 Transitions: Separate different transitions by Scene Root\n\nChange-Id: I42e80dac6097fee740f651dcc0535f2c57c11ebb\n"
    },
    {
      "commit": "4f5072327d00822a2bfaff56df46cea2981ac90d",
      "tree": "d3589b68e6e529e087088dc967bef41a8815a92e",
      "parents": [
        "6b1d5a4ff220378407e19b7733e727be88b41376"
      ],
      "author": {
        "name": "Chet Haase",
        "email": "chet@google.com",
        "time": "Mon Jun 10 13:00:06 2013 -0700"
      },
      "committer": {
        "name": "Chet Haase",
        "email": "chet@google.com",
        "time": "Mon Jun 10 14:06:14 2013 -0700"
      },
      "message": "Add dynamic scene creation/transition capability\n\nAdd TransitionManager.beginDelayedTransition() to handle starting a transition\non the next frame for a given scene root based on all changes that\ntake place between the first call to that method and the next animation frame.\n\nIssue #9321937 Transitions: consider batching up multiple scene actions\n\nChange-Id: I3fc92b6b4ec5ff42b1e678bcfd385703e32eba2a\n"
    },
    {
      "commit": "867a86613d4152a93423300f83597300e6ebeebe",
      "tree": "9087a8ca942f453fb2da7555cd04c5aa2083213d",
      "parents": [
        "d18607980d86f03ffd838321ac3d511fa820b3e0"
      ],
      "author": {
        "name": "Chet Haase",
        "email": "chet@google.com",
        "time": "Mon Jun 03 07:30:21 2013 -0700"
      },
      "committer": {
        "name": "Chet Haase",
        "email": "chet@google.com",
        "time": "Mon Jun 03 16:37:05 2013 -0700"
      },
      "message": "Various fixes/cleanup in Scenes and Transitions\n\nsetDuration() wasn\u0027t handled correctly for TransitionGroup; it should\npropagate the value to its children.\n\nAlso, videos with no ids were not being handled correctly. The transition code was\nusing the default id on those views (-1) to store start/end data about the view,\ncausing multiple non-id views to clobber values in the hashmaps. The correct approach\nshould be to ignore default id values - only store information about the view\ninstances, not about the unset ids.\n\nAlso, added a new test InterruptTest to be used to fix the current behavior of\nnot handling situations where new transitions start while old ones are still taking place.\n\nChange-Id: I4e880bdbb33cc26d487bceb0d56e463e72f7621f\n"
    },
    {
      "commit": "faebd8f0795b7d275fb4e503533c8c0c4a9acc21",
      "tree": "464de8bb5dcd9ae99402ebb630d329dc8ce953cc",
      "parents": [
        "b3caa9200a61cde1178a2c83419de56579d3c5a5"
      ],
      "author": {
        "name": "Chet Haase",
        "email": "chet@google.com",
        "time": "Fri May 18 14:17:57 2012 -0700"
      },
      "committer": {
        "name": "Chet Haase",
        "email": "chet@google.com",
        "time": "Thu Apr 18 13:33:13 2013 -0700"
      },
      "message": "First draft of Scenes \u0026 Transitions feature\n\nThis checkin has preliminary API (in flux, definitely changes still\nto be made) and implementation for a new \"Scenes \u0026 Transitions\" feature.\nThe current implementation allows you to define different Scenes\n(via layout resource IDs or callbacks) and Transitions to be used when\nchanging to those scenes. By default, scene changes will use AutoTransition,\nwhich generally does the right thing.\n\nThere are no overview docs or tutorials yet. The best way to learn how things\nwork is to see the code for the various tests in\nframeworks/base/tests/TransitionTests.\n\nExpect the API to change. Expect the implementation to change (mostly to add\nmore functionality). Expect bugs, but tell me if things do not work\nas expected.\n\nChange-Id: Ib025a9f565678b225afa4759325cf6d496cc7215\n"
    }
  ]
}