Skip to main content

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

  • From: Volker Bauche < >
  • To:
  • Subject: [jsr361-experts] Re: [jsr361-observers] Re: Re: Power management Updates
  • Date: Fri, 02 Aug 2013 18:49:28 +0200

Sure. With saying "thanks for comments" to Roger, I meant also "I'll take your remarks into account" :-)

-Volker

Am 02.08.2013 18:44, schrieb Werner Keil:
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 < <mailto: >> 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:* 

    
<mailto: >
    *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)

                                   throwsPowerManagerException  
<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)

                                    throwsPowerManagerException  
<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 

        
<mailto: >:

            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