Lines Matching full:wakelock
137 because the requests take considerable time, RIL Java releases the wakelock
141 wakelock and process the response, and later go to idle state again. This
145 <li>If the response time isn't long enough then holding the wakelock and
147 power efficient than going in suspend state by releasing the wakelock and
180 example, <code>RIL_REQUEST_GET_AVAILABLE_NETWORKS</code>), then wakelock
186 <p>In this scenario, wakelock equivalent is held by Modem code (RIL request
194 <li>RIL request is sent, and the modem needs to acquire wakelock to process
198 the wakelock counter and release it if the wakelock counter value is 0.</li>
201 vendor code that acquires wakelock and sends a response to ril.cpp. ril.cpp
202 then acquires wakelock and sends a response to the Java side.</li>
204 <li>When the response reaches the Java side, wakelock is acquired and response
209 releases the wakelock that was acquired in step 3.</li>
212 <p>Note that the wakelock timeout duration for the request-ack sequence
218 <p>In this scenario, wakelock is not held by modem and response is quick
229 <li>Vendor code doesn't need to acquire wakelock and can process the request
233 <code>decrementWakeLock()</code> is called, which decreases wakelock counter
234 and releases wakelock if the counter value is 0.</li>
244 <p>As shown in the above diagram, RIL unsolicited responses have a wakelock
245 type flag in the response that indicates whether a wakelock needs to be
247 the flag is set, then a timed wakelock is set and response is sent over a
248 socket to the Java side. When the timer expires, the wakelock is released.</p>
252 <p>The timed wakelock illustrated in Scenario 2 could be too long or too
261 a timed wakelock on the native side while sending an unsolicited response.</p>
285 vendors should do some internal testing to find out if using the new wakelock
