1. 17 Jan, 2012 3 commits
  2. 13 Jan, 2012 1 commit
  3. 12 Jan, 2012 1 commit
  4. 11 Jan, 2012 7 commits
    • Dima Zavin's avatar
      rootdir: convert all usages of $prop to ${prop} · f90b0e04
      Dima Zavin authored
      
      Change-Id: Ic2472606e869d23c0f499a192cd7bb21ca3cf5b5
      Signed-off-by: default avatarDima Zavin <dima@android.com>
      f90b0e04
    • Dima Zavin's avatar
      init: use init's property expansion code for setprop/write · 84bf9af7
      Dima Zavin authored
      
      Change-Id: I3c284860cc8d5106ac2b086e62baeb6263873935
      Signed-off-by: default avatarDima Zavin <dima@android.com>
      84bf9af7
    • Dima Zavin's avatar
      init: delay importing files until after parsing the current file · 78a1b1fe
      Dima Zavin authored
      
      If we process the import directive inline, then the ordering of the
      commands for the "on xxx" sections would be a little unexpected. The
      init.rc files do not really have an implied  order as to which section
      appears and gets processed first. The init code itself provides that
      ordering explicitly. For the user, the expectation is that if both the
      current file and the imported file define a section (e.g. "on init"),
      then the commands in the current file will be executed first, and then
      the ones from the imported file(s).
      
      The current implementation did not do that. It processed the import
      directive inline, and thus the imported (i.e. dependent) files would
      appear first in the command lists for the sections. This created
      unintended side effects and the solution would have been to try and
      put the import lines somewhere in the middle of the init file. This
      would be difficult to notice and hard to extract the dependencies.
      
      To solve this, we add the imports to a list for each file being parsed
      and process the list after finishing parsing the file. This provides
      predictable order for imports and provides a logical flow from the
      user perspective: the currently parsed file gets to run its commands
      before the files being imported.
      
      Change-Id: I06dc35ff286314060e16b18923683cd2787269de
      Signed-off-by: default avatarDima Zavin <dima@android.com>
      78a1b1fe
    • Dima Zavin's avatar
      init: export all androidboot cmd line values as ro.boot.xx props · 5511c84a
      Dima Zavin authored
      
      Also, clean up how we initialize the ro.xx properties and process
      the kernel command line.
      
      Change-Id: Iedda6c90e31340a189171a44b2767480403354f7
      Signed-off-by: default avatarDima Zavin <dima@android.com>
      5511c84a
    • Dima Zavin's avatar
      init: import the hardware specific init file in init.rc · 3e7b7739
      Dima Zavin authored
      
      This removes the hardcoding of the file import in init and instead
      allows the init.rc file to fully control what is loaded.
      
      Change-Id: I933e5bbab57f1e8705a370d660f92c6508da94d2
      Signed-off-by: default avatarDima Zavin <dima@android.com>
      3e7b7739
    • Dima Zavin's avatar
      init: allow init file imports to use properties in names · a6235eac
      Dima Zavin authored
      
      Adds new property syntax in init files during init file filename
      expansion during the import command:
      ${prop.name}
      
      So, one can do:  import /init.${ro.hardware}.usb.rc
      
      Should convert other usages of property names to use the new function.
      
      Change-Id: I9205d7d7a2da620bc8e6b89ac0eb554fad53ded3
      Signed-off-by: default avatarDima Zavin <dima@android.com>
      a6235eac
    • Dima Zavin's avatar
      init: initialize property area early at boot · d7634c9c
      Dima Zavin authored
      
      The property service is still started later, but the property area
      and the initial boot properties are initialized before the init.rc
      file is processed. This allows init.rc files to have access to boot
      properties during parsing.
      
      Change-Id: Iae9ed1093c821831a864b39ae6bc697e62b94757
      Signed-off-by: default avatarDima Zavin <dima@android.com>
      d7634c9c
  5. 09 Jan, 2012 1 commit
  6. 29 Dec, 2011 1 commit
  7. 14 Dec, 2011 2 commits
  8. 13 Dec, 2011 4 commits
  9. 10 Dec, 2011 1 commit
  10. 09 Dec, 2011 1 commit
    • Christopher Tate's avatar
      Fix 'adb backup' on Windows · b1dfffe6
      Christopher Tate authored
      Use the same call sequence that 'adb pull' uses for creating the
      output file.  adb_open_mode() apparently does not work on Windows
      hosts.
      
      Bug 5733007
      
      Change-Id: I48d719c4657c93e19f6790cf1c6da610d49f5806
      b1dfffe6
  11. 08 Dec, 2011 1 commit
  12. 06 Dec, 2011 1 commit
  13. 05 Dec, 2011 2 commits
  14. 28 Nov, 2011 1 commit
  15. 22 Nov, 2011 3 commits
  16. 21 Nov, 2011 1 commit
    • Nick Pelly's avatar
      Replace vendor specific NfcGoogle.apk with generic Nfc.apk · 097b4ed4
      Nick Pelly authored
      The access control changes allow us to just use Nfc.apk with
      the regular platform certificate, instead of the custom signed
      NfcGoogle.apk. So we can compeltely get rid of vendor/google/apps/NfcGoogle
      and just build it out of packages/apps/Nfc now.
      
      The package name is also reverted from com.android.nfc3 to com.android.nfc
      
      The NFC uid needs to get bumped (25 to 27) to allow the cert change.
      
      Bug: 5608249
      Change-Id: I5e178b469e5210cd231ba5f4ea57aa666b3d8893
      097b4ed4
  17. 17 Nov, 2011 2 commits
  18. 16 Nov, 2011 4 commits
  19. 15 Nov, 2011 2 commits
  20. 10 Nov, 2011 1 commit