On Thu, Aug 7, 2014 at 8:43 AM, Ehsan Akhgari <[email protected]> wrote: > On 2014-08-02, 8:05 PM, Jonas Sicking wrote: >> >> Hi All, >> >> We have many times debated how to handle engineering mode. Various >> partners have so far been adding in custom solutions on their own >> branches, but it would be good to find a better solution. >> >> Below is one proposed solution, though I'm definitely open to other >> ones. However the goals I'd like to accomplish are: >> >> A) The commands that can be triggered in the service menu is going to >> be fairly OEM specific and not something that makes sense to build >> into Gecko as cross-device-cross-device code. >> B) The smaller Gecko/Gaia changes needed by OEMs the better. This is >> to simplify porting the implementation forward to future FirefoxOS >> releases. >> C) We would like to one day be able to roll out updates to phones >> without requiring OEMs to reapply their own changes to the updated >> release. >> D) The back-end of the service menu needs to be at least partially >> implemented in C++. I.e. some of the commands that can be triggered >> can't be implemented using the currently exposed APIs, even including >> certified APIs. >> F) The service menu UI should be implemented as a separate FirefoxOS >> HTML app. I.e. we don't want to use some other rendering mechanism >> than what we already have. And we don't want to have to add a lot of >> engineering mode code to any of the normal gaia apps. >> G) There shouldn't need to be a user visible icon on the home screen >> for launching engineering mode. >> H) It would be ideal, though not strictly required, if it was possible >> to launch engineering mode by using a key combination in the dialer >> app since this is how OEMs are used to doing it today. >> >> Based on that I recommend the following setup: >> >> 1) Add a gaia-setting for "key combination in dialer that triggers >> service mode". >> 2) Change the dialer app to read this setting and wait for the correct >> key combination to be triggered. >> 3) When the combination has been hit, let the dialer app launch an >> activity called "internal-system-engineering-mode". >> 4) Change web activities to enforce that activity names starting with >> "internal-system-" can only be initiated and handled by certified >> apps. >> 5) Add a XPCOM interface and an XPCOM contract-id for engineering >> mode. The interface would have functions for >> getValue/setValue/message. See below >> 6) Create a certified-only WebAPI which handles the IPC and security >> checks to enable an app to use the above XPCOM interface. >> >> The XPCOM interface would look something like: >> >> // Implemented by engineering-mode library >> interface nsIEngineeringMode >> { >> DOMString getValue(in DOMString name); >> void setValue(in DOMString name, in DOMString value); >> void setMessageHandler(in nsIEngineeringModeMessageHandler handler); >> } >> >> interface nsIEngineeringModeMessageHandler >> { >> void handleMessage(DOMString message); >> } >> >> and the contract id would be something like >> "@mozilla.org/b2g/engineering-mode;1" >> >> >> And the WebAPI would look something like >> >> interface EngineeringMode { > > > Small nit: This needs to derive from EventTarget, obviously!
Yes. >> Promise<DOMString> getValue(DOMString name); >> void setValue(DOMString name, DOMString value); > > > Shouldn't setValue return a Promise<void> instead? I can imagine that the > services app may want to wait until a specific setValue call to finish > successfully before proceeding further. My thinking was to keep things simple. The code can always send a message once a 'set' succeeds. But it might make sense as a convenience to make EngineeringMode.setValue reject a promise if the nsIEngineeringMode.setValue function returns an error nsresult. / Jonas _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
