Use Date/Time on Android Device for Fallback Logging #1356

rmartin16 · 2023-07-11T19:50:45Z

Changes

Fixes Android crash logs are hidden if phone and computer times aren't in sync #1146
When the PID for the app on an Android device is not found, the fallback app streaming method will use a datetime from the device instead of the host machine as the start time to show logs.

Notes

I'm operating under the assumption that Android's date command has supported this formatting for as long as we've needed it to.
I'm also currently aborting if obtaining the device datetime goes wrong since such a contingency seems really unlikely to be necessary when things are working otherwise.

PR Checklist:

All new features have been tested
All new features have been documented
I have read the CONTRIBUTING.md file
I will abide by the code of conduct

mhsmith · 2023-07-11T19:52:59Z

I'm operating under the assumption that Android's date command has supported +%s formatting for as long as we've needed it to.

The Briefcase Android template currently has a minimum API level of 24, so if you can confirm it works on an emulator with that version, that should be good enough.

rmartin16 · 2023-07-11T20:21:43Z

I'm operating under the assumption that Android's date command has supported +%s formatting for as long as we've needed it to.

The Briefcase Android template currently has a minimum API level of 24, so if you can confirm it works on an emulator with that version, that should be good enough.

Thanks. I changed AndroidSDK.DEFAULT_SYSTEM_IMAGE to return system-images;android-24;default;x86_64 instead of system-images;android-31;default;x86_64 and the date is returned correctly for an emulator using that system image. I believe this effectively tests API 24 as the oldest supported Android.

freakboy3742

Looks good for the most part; one question about timezone, since it wasn't immediately obvious; it might not be revealed in testing because you're running locally UTC negative will work in your favor for testing purposes.

freakboy3742 · 2023-07-12T03:23:20Z

src/briefcase/integrations/android_sdk.py

+ """Obtain the device's current date/time."""
+ try:
+ # request datetime in seconds since Unix epoch
+ return datetime.fromtimestamp(int(self.run("shell", "date", "+%s")))


Just confirming: is this using UTC epoch or local timezone epoch?

hmm...so, if datetime.fromtimestamp() isn't given a timezone, then it returns a naive date/time for the platform's date/time configuration.

In practice, this assumes the device and the host machine are configured for the same timezone....and daylight saving...and whatever else....

I suppose this requirement could be avoided if a specific format is requested from date on the device and an equivalent format is specified for datetime.strptime()

Look, we can all agree that time was invented by the devil to punish programmers. :-)

We could definitely go to great lengths to ensure timezone compliant round trips - but I'm not sure that's actually required. We just need to make sure that the time that comes back from adb shell date is in the same timezone as the log file filter. If that's true with fromtimestamp(), then I'm 99% happy; the remaining 1% is to document the new datetime() endpoint to make sure nobody tries to use it for anything else in future.

Look, we can all agree that time was invented by the devil to punish programmers. :-)

If that isn't the truth....

We could definitely go to great lengths to ensure timezone compliant round trips - but I'm not sure that's actually required. We just need to make sure that the time that comes back from adb shell date is in the same timezone as the log file filter. If that's true with fromtimestamp(), then I'm 99% happy; the remaining 1% is to document the new datetime() endpoint to make sure nobody tries to use it for anything else in future.

Well...I guess as long as 99% of the time users' devices have date/time configurations that match their machines that are running Briefcase....then we're good here :/

This is why I had to commit c2e4b6b after pushing; I discovered that GitHub's CI runners are configured for UTC (as opposed to my EDT) and were returning a different date/time for the same value returned from date on the device.

I could play around with explicit date/time formats tomorrow to see what this takes.

ed9c234 will ensure this logging date/time is local to the device.

- The Unix epoch is always UTC and `fromtimestamp()` returns a date/time that's local to the machine; therefore, if the timezone of the machine is different than the device, the date/time will not match the local date/time of the device. - To avoid this, a specific date/time format is requested from the device so it can be parsed on the machine in a timezone-unaware fashion.

mhsmith

I can't reliably reproduce my original problem now, and I suspect it may actually have been an intermittent issue with it failing to find the PID even when the app is running. But anyway, this all looks fine to me.

rmartin16 · 2023-07-12T22:03:49Z

fwiw...I was only able to not find a PID when I commented out pid = adb.pidof(package, quiet=True)...even when I invoked a bad import during Python startup, it always found the PID from my main machine.

Though, on a sufficiently slow machine (like my Pi 4b), every once in a while, it doesn't find a PID in 5 seconds and then runs logcat_tail() before the app even crashes. I also even noticed once that Briefcase "forcibly killed gradle" when trying to exit the output streamer. I highly suspect my Pi is not cpu limited in these cases....but disk limited since it's all running on a tiny micro sd card. Probably not anything that deserves changes right now....but some interesting data points from a slower machine.

freakboy3742

Looks good to me. The failure mode you describe on RPi/slow machines is definitely a problem, but it's sufficiently edge case that I can definitely live with it for now. The only immediately obvious fix I can think of would be to increase the 5s window to something more, but 5s is already inconvenient for people with fast machines, and there's essentially no delay that will be long enough for a sufficiently slow machine.

If we can find a different marker that allows us to differentiate between "The app has crashed" and "the app hasn't started... yet", that would be great - but in the meantime, this will be a significant improvement for the 95% case of app developers who have an app failing on startup and a device with a clock discrepancy.

rmartin16 added 2 commits July 11, 2023 15:23

Use the Android device datetime for logcat fallback start time

b96cdc9

Use a fixture for ADB testing

d1723b9

rmartin16 added 2 commits July 11, 2023 15:56

Add changenote

1d3184d

Fix ADB datetime test not to assume local timezone

c2e4b6b

freakboy3742 requested changes Jul 12, 2023

View reviewed changes

rmartin16 requested a review from freakboy3742 July 12, 2023 15:28

mhsmith approved these changes Jul 12, 2023

View reviewed changes

freakboy3742 approved these changes Jul 12, 2023

View reviewed changes

freakboy3742 merged commit b6057a0 into beeware:main Jul 12, 2023
32 of 35 checks passed

rmartin16 deleted the adb-device-time branch July 12, 2023 23:51

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use Date/Time on Android Device for Fallback Logging #1356

Use Date/Time on Android Device for Fallback Logging #1356

rmartin16 commented Jul 11, 2023 •

edited

Loading

mhsmith commented Jul 11, 2023

rmartin16 commented Jul 11, 2023

freakboy3742 left a comment

freakboy3742 Jul 12, 2023

rmartin16 Jul 12, 2023 •

edited

Loading

rmartin16 Jul 12, 2023

freakboy3742 Jul 12, 2023

rmartin16 Jul 12, 2023

rmartin16 Jul 12, 2023

mhsmith left a comment •

edited

Loading

rmartin16 commented Jul 12, 2023 •

edited

Loading

freakboy3742 left a comment

Use Date/Time on Android Device for Fallback Logging #1356

Use Date/Time on Android Device for Fallback Logging #1356

Conversation

rmartin16 commented Jul 11, 2023 • edited Loading

Changes

Notes

PR Checklist:

mhsmith commented Jul 11, 2023

rmartin16 commented Jul 11, 2023

freakboy3742 left a comment

Choose a reason for hiding this comment

freakboy3742 Jul 12, 2023

Choose a reason for hiding this comment

rmartin16 Jul 12, 2023 • edited Loading

Choose a reason for hiding this comment

rmartin16 Jul 12, 2023

Choose a reason for hiding this comment

freakboy3742 Jul 12, 2023

Choose a reason for hiding this comment

rmartin16 Jul 12, 2023

Choose a reason for hiding this comment

rmartin16 Jul 12, 2023

Choose a reason for hiding this comment

mhsmith left a comment • edited Loading

Choose a reason for hiding this comment

rmartin16 commented Jul 12, 2023 • edited Loading

freakboy3742 left a comment

Choose a reason for hiding this comment

rmartin16 commented Jul 11, 2023 •

edited

Loading

rmartin16 Jul 12, 2023 •

edited

Loading

mhsmith left a comment •

edited

Loading

rmartin16 commented Jul 12, 2023 •

edited

Loading