Skip to main content

[jsr361-experts] Re: [jsr361-observers] Re: Power management Updates

  • From: Werner Keil < >
  • To:
  • Subject: [jsr361-experts] Re: [jsr361-observers] Re: Power management Updates
  • Date: Fri, 2 Aug 2013 18:44:57 +0200

So as Roger also mentioned, is "urgency" a boolean flag, in which case
"isUrgent" could be a better name, or is it some sort of "urgency scale"?

Werner

On Fri, Aug 2, 2013 at 5:41 PM, Volker Bauche 
< >wrote:

>  @Roger: Thanks for comments.
> @Thomas: I guess those are the same expectations as for
> setPowerState<http://../../../javax/microedition/power/PowerManager.html#setPowerState%28int,%20boolean%29>
> ( 
> PowerStateEvent.POWER_STATE_OFF<http://../../../javax/microedition/power/PowerStateEvent.html#POWER_STATE_OFF>,
> urgency),
> right?
> So I assume your email indirectly answers Roger's questions in the third
> bullet.
> I'll add those requirements into the javadocs of both methods then.
>
> BR-
> Volker
>
> Am 02.08.2013 17:10, schrieb Lampart Thomas:
>
>  Dear all,****
>
> ** **
>
> One comment about shutdown or reboot behavior:****
>
> ** **
>
> My expectations would be that these methods do return and the midlet can
> basically continue.****
>
> But then when shutting down the device Java should be shut down properly,
> i.e. all midlets get a call to their destroyApp() method.****
>
> ** **
>
> Kind regards****
>
>   thomas****
>
> ** **
>
> *From:* roger riggs 
> [mailto: < >]
>
> *Sent:* Freitag, 2. August 2013 17:06
> *To:* 
> 
> *Subject:* [jsr361-experts] Re: Power management Updates****
>
> ** **
>
> Hi Volker,
>
> Looks pretty good.****
>
>    - The "urgency" argument would be clearer as "urgent"  true|false
>    (Also in the rest of the PowerManager too)****
>    - enableRadio should return the new old (boolean) state of the radio;
>    since there is otherwise no way to know if changed the state.****
>    - In the rebootDevice method (and in the case of Power_OFF) is there
>    any expectation of orderly stopping of applications?  Is there any
>    expectation of how soon the device must take the action?
>    In particular, is the method expected even to return?****
>
>
> typo:
>   "flase" -> "false"
>  "Switchs" -> "Switches"****
>
> On 8/2/2013 5:22 AM, Volker Bauche wrote:****
>
>  Dear experts,
>
> here comes an answer in response to Thomas' request to introduce
> a possibility to reboot the system and switch the RF unit on or off.
>
> The proposal would be to add the following two methods into the
> javax.microedition.power.PowerManager class:
>
>
> ****
>
> public abstract void enableRadio(boolean state,****
>
>                boolean urgency)****
>
>                           throws PowerManagerException 
> <http://../../../javax/microedition/power/PowerManagerException.html>,****
>
>                                  java.lang.SecurityException****
>
>  Switchs the radio (RF unit) of a device on or off. If the device does
> not have a radio, a call to this method is ignored. An attempt to switch
> the RF off if it is off already, or to switch it on in case it is on
> already is ignored as well. ****
>
> Applications suites that want to call this method with the urgency parameter
> set to false have to require the 
> PowerStatePermission<http://../../../javax/microedition/power/PowerStatePermission.html>
>  with name "set". Applications suites that want to call this method with
> the urgency parameter set to true have to require the 
> PowerStatePermission<http://../../../javax/microedition/power/PowerStatePermission.html>
>  with name "setUrgent". Implementations are recommended to grant this
> permissions only to pre-installed system applications though.****
>
> *Parameters:***
>
> state - true in order to switch the radio on, flase to switch it off****
>
> urgency - If urgency is set to true, force the system to change the radio
> state regardless of any objections which may be posted by applications to
> reject the state change.****
>
> *Throws:***
>
> PowerManagerException<http://../../../javax/microedition/power/PowerManagerException.html>
>  - A PowerManagerException MUST be thrown with error code
> KEEP_CURRENT_STATE if an error is encountered during the radio state
> change process.****
>
> java.lang.SecurityException - A SecurityException MUST be thrown if the
> caller does not have the valid permission to initiate the call.****
>
>
> =================================================================================================================================================
> ****
>
> public abstract void rebootDevice(boolean urgency)****
>
>                            throws PowerManagerException 
> <http://../../../javax/microedition/power/PowerManagerException.html>,****
>
>                                   java.lang.SecurityException****
>
>  Initiates a reboot of the device. For this, the power state is set to
> PowerStateEvent.POWER_STATE_OFF<http://../../../javax/microedition/power/PowerStateEvent.html#POWER_STATE_OFF>,
> as it would happen by a call to 
> setPowerState<http://../../../javax/microedition/power/PowerManager.html#setPowerState%28int,%20boolean%29>
> ( 
> PowerStateEvent.POWER_STATE_OFF<http://../../../javax/microedition/power/PowerStateEvent.html#POWER_STATE_OFF>,
> urgency), but dispositions are made, that the device boots again
> aferward. The power state the device is in after rebooting is
> implementation dependent. ****
>
> Applications suites that want to call this method with the urgency parameter
> set to false have to require the 
> PowerStatePermission<http://../../../javax/microedition/power/PowerStatePermission.html>
>  with name "set". Applications suites that want to call this method with
> the urgency parameter set to true have to require the 
> PowerStatePermission<http://../../../javax/microedition/power/PowerStatePermission.html>
>  with name "setUrgent". Implementations are recommended to grant this
> permissions only to pre-installed system applications though.****
>
> *Parameters:***
>
> urgency - If urgency is set to true, force the system to reboot
> regardless of any objections which may be posted by applications to reject
> the state change.****
>
> *Throws:***
>
> PowerManagerException<http://../../../javax/microedition/power/PowerManagerException.html>
>  - A PowerManagerException MUST be thrown with error code
> STATE_TRANSITION_FAILURE if an error is encountered during the rebooting
> process. A PowerManagerException MUST be thrown with error code
> ILLEGAL_STATE_TRANSITION_REQUEST if a state transition to
> PowerStateEvent.POWER_STATE_OFF<http://../../../javax/microedition/power/PowerStateEvent.html#POWER_STATE_OFF>
>  is invalid.****
>
> java.lang.SecurityException - A SecurityException MUST be thrown if the
> caller does not have the valid permission to initiate the call.****
>
>
> =================================================================================================================================================
> ****
>
> @Thomas: Pls. let me know if this meets your expectations.
> @All: Pls. let me know about any concerns.****
>
> Thanks -
> Volker****
>
>
> Am 01.08.2013 16:35, schrieb 
>  :****
>
> Dear experts,****
>
> ** **
>
> here come the minutes of today's telco.****
>
> ** **
>
> - Latest uploaded version contains just editorial changes, no****
>
> modifications of the API since last one. Mainly the description of****
>
> provisioning has been improved in order to make clearer which****
>
> requirements are common (independent on the chosen provisioning****
>
> mechanism), and which are OTA provisioning specific.****
>
> ** **
>
> - Thomas has asked for some additional changes in the power management****
>
> package: a possibility to go into airplane mode (while this might not****
>
> be the right term as it is unlikely - but not impossible! :-) - for an****
>
> embedded device to go aboard a plane, but this is rather for switcching****
>
> off the radio in order to spare power) and a possibility to initiate a****
>
> reboot (which is not exactly a feature of power management, but it****
>
> seems to be the best place for it)****
>
> AI: Volker to provide a proposal****
>
> ** **
>
> - Werner had some questions about optionality and the demarcation****
>
> between packages, which could be clarified during the call.****
>
> ** **
>
> - Thomas and Werner claimed about the confusing version strings used in****
>
> the spec. Currently we have:****
>
> MEEP 8 a a platform-level name****
>
> MEEP 8 as the name of the spec****
>
> MEEP-1.0.0 as the profile version****
>
> MEEP-1.0 as the value for microedition.profile****
>
> The reason is that MEEP is part of the ME8 platform, but it is the****
>
> first version of MEEP. The proposal is (as a compromise) to change at****
>
> least the profile version into MEEP-1.8.0 and the value of****
>
> microedition.profile into MEEP-1.8****
>
> (as we have it for CLDC)****
>
> AI Volker to clarify this with the ME8 architects****
>
> ** **
>
> - Public Review of the spec is planned for end of August; for this we****
>
> have to provide documents to PMO until August 15. Issues that should be****
>
> resolved before PR should be raised asap.****
>
> ** **
>
> - I will send out an email soon in order to ask you to formally confirm****
>
> that you have no concerns against going into PR phase.****
>
> ** **
>
> Best regards -****
>
> Volker****
>
>  ** **
>
> ** **
>
>


[jsr361-experts] Minutes of EG meeting on August 1, 2013

volker.bauche 08/01/2013

[jsr361-experts] Re: [jsr361-observers] Minutes of EG meeting on August 1, 2013

Werner Keil 08/01/2013

[jsr361-experts] Re: [jsr361-observers] Minutes of EG meeting on August 1, 2013

Volker Bauche 08/01/2013

[jsr361-experts] Power management Updates

Volker Bauche 08/02/2013

[jsr361-experts] Re: Power management Updates

Lampart Thomas 08/02/2013

[jsr361-experts] Re: Power management Updates

roger riggs 08/02/2013

[jsr361-experts] Re: Power management Updates

Lampart Thomas 08/02/2013

[jsr361-experts] Re: Power management Updates

Volker Bauche 08/02/2013

[jsr361-experts] Re: [jsr361-observers] Re: Power management Updates

Werner Keil 08/02/2013

[jsr361-experts] Re: [jsr361-observers] Re: Re: Power management Updates

Volker Bauche 08/02/2013
 
 
Close
loading
Please Confirm
Close