Status Update
No update yet.
Comments
su...@google.com
dr...@gmail.com
Here is what I found:
On API 31+, time was not updated after the host was waken up. While on API 30 and under, time was updated after host was waken up. The main difference is caused by switching the modem simulator. In API 30 and under, time will be updated whenever signal strength query is received.
Looking at the code in API 31+ for time update when signal strength query is received, I think it is possible that timeUpdate is not invoked
void NetworkService::HandleSignalStrength(const Client& client) {
std::vector<std::string> responses;
std::stringstream ss;
if (WakeupFromSleep()) {
misc_service_->TimeUpdate();
} else if (first_signal_strength_request_) {
first_signal_strength_request_ = false;
misc_service_->TimeUpdate();
}
android_last_signal_time_ = time(0);
auto response = BuildCSQCommandResponse(GetCurrentSignalStrength());
responses.push_back(response);
responses.push_back("OK");
client.SendCommandResponse(responses);
}
dr...@gmail.com
ra...@google.com
Still seeing this issue with Emulator 31.3.14 Stable. Refer to the screenshot.
dr...@gmail.com
@devki How do I know if the fix is in 31.3.14 stable? Any tool for checking if a CL went into the specified version?
ra...@google.com
dr...@gmail.com
RE#9 Thanks Devki. Actually the fix is included in aosp-emu-31-release branch.
ra...@google.com
Upload a new
Description
When I set up a periodic job, I want the first in the series to be performed INSTANTLY (the user expects it... they hit a button and are waiting for an immediate result), and then for subsequent ones to be performed based on the periodic schedule (more vague timings is fine... the user is no longer waiting).
When you set up a periodic work request *without* a flex interval, it can run anytime in the set interval, i.e. from NOW until the end of the interval. If the device is awake when the periodic work request is scheduled, which is the case for me, I find that the first work in the series is generally performed at the START of the interval, i.e. NOW... though "NOW" may not be instantly (it's up to the device to decide... may be delayed a few seconds).
Because it cannot be guaranteed that the first periodic work will be performed *instantly*, instead I do an explicit call to the work-performing function outside of the WorkManager realm, and put a flexInterval on the periodic work of 5 mins so that the first periodic work will certainly not be performed straight away, but instead it will be near the end of the first period, most likely 5 mins before the end. This is not quite ideal (first gap between work runs is not quite a full interval) but it's OK... the user won't care or even notice it runs 5 mins "early" the first time.
Now, I thought that the ability to set an "initialDelay" in 2.1.0 would solve my problems... so that I could:
(a) still make an explicit call to the work-performing function to do the immediate work, guaranteed to be NOW (the user expects that)
(b) set up a periodic work request WITHOUT flexInterval (i.e. use the whole interval) and WITH an initial delay equal to the period "interval"
That way, I get the immediate work done, and then after "interval" the periodic work request is scheduled, and because (let's assume) the device is still awake, the first periodic work will likely perform at the START of the interval, i.e. almost straight away, i.e. pretty close to exactly one "interval" after the user set the schedule going.
BUT I'm not finding that. Let's say that "interval" of the periodic work is 15 mins, and I set an "initial delay" also of 15 mins, and I set this going when the user hits the button. I find that the immediate work is performed at 0 mins (triggered explicitly, not by WorkManager, so that's as expected), then at 15 mins NOTHING happens, and only at 30 mins does the first periodic work actually run.
It seems that either the first periodic work happens at the END of the first interval (15-30 mins) and not the start (like it usually does, if the device is awake and not busy), or WorkManager delayed first periodic interval to be at 30-45 mins, i.e. it waited 30 mins not 15 mins, twice what I asked for.
So, how is "setInitialDelay" for a periodic work request meant to work? It doesn't just wait "delay" (instead of not waiting at all) and then enqueue the periodic work request?