Most app development platforms allow the developer to push an app that's being developed locally directly to the device for quick develop/test/debug cycles. We should have support for this, too. For packaged apps, this could be pretty easy if we could convince Gecko to update an app from a different location (i.e. the local file system where we adb push the new manifest.webapp and application.zip files to). A more hack-ish way would be to push new application.zip and manifest.webapp files to the device, and update webapps.json while Gecko isn't running. The simulator add-on does it that way [1]. However, some Gecko support is still needed because permissions need to be updated as well. The simulator currently does not do this. For hosted apps, we could use the first-start code path [2] that puts files found in $webappsProfileDir/webapps/<appId>/cache into the appcache and also updates permissions [3]. I've tried cobbling something like that together in an add-on [4]. However, there's a good question whether it actually makes sense to do this for hosted apps since you could just test these in a web browser / with an ad-hoc web server. There's little functional difference. [1] https://github.com/mozilla/r2d2b2g/blob/master/addon/lib/main.js#L131 [2] https://mxr.mozilla.org/mozilla-central/source/dom/apps/src/OfflineCacheInstaller.jsm#102 [3] https://mxr.mozilla.org/mozilla-central/source/dom/apps/src/PermissionsInstaller.jsm [4] https://github.com/philikon/incubator-cordova-b2g/blob/master/build/addon/bootstrap.js#L76

Here's a low-tech idea: we do what the simulator currently does, e.g.: 1. kill gecko 2. read webapps.json, determine the app's appId, update webapps.json if necessary (e.g. first install) 3. push the new manifest.webapp and source code (either as applications.zip or a 'cache' directory, depending on whether it's a packaged app or not) to $webappsProfileDir/webapps/<appId>/ 4. add a pref to $ProfD/prefs.js that lets Gecko know it should update app cache and permissions for appId at startup. 5. start gecko The patch makes step 4 possible in gecko: at startup we read read a pref and if it exists, we update app cache and permissions for the app it specifies. This would allow us to write a script that does steps 1-5 on the desktop computer. What do folks think?

Comment on attachment 685882 [details] [diff] [review] idea v1 Review of attachment 685882 [details] [diff] [review]: ----------------------------------------------------------------- That could work, but I don't like the idea of trusting the host script to create the localId in webapps.json since this is what we use to grant permissions. I would rather let the host script push application.zip, manifest.webapp, update.manifest and a metadata.json similar to the one we use in gaia/external-apps (see bug 817982) and run a pseudo install step from there. The stop/start sequence is also not ideal, but we can live with that initially. In phase 2 we should rather do something like listening on a pipe for commands, or use the remote debugger.

Core Graveyard / DOM: Apps is inactive. Closing all bugs in this component.