3 ms·

I had a similar problem when I updated to Android 10 and the MediaStore content provider decided to get stuck in an infinite loop trying to upgrade its database

I had a similar problem when I updated to Android 10 and the MediaStore content provider decided to get stuck in an infinite loop trying to upgrade its database. I couldn't take screenshots, use the camera, or use any functionality in any apps that would rely on the photo gallery. Now, that's me, a long time Android app developer, and it took me an hour to figure out what the hell happened (wiping the data for said content provider fixed everything, obviously). Imagine what would a regular user do if they encountered this issue? I had a fully-stock installation too, didn't even unlock the bootloader. I don't understand why modern software has to suck so much. If you can't perform some operation for some reason, for the love of god, at least show a sensible error message so people who haven't spent ridiculous amounts of time reading the source code of your product as part of their job can troubleshoot their systems. Not "something failed, go read logcat, maybe it helps, good luck".

read_if_gay_ 6y ago
> at least show a sensible error message so people who haven't spent ridiculous amounts of time reading the source code of your product as part of their job can troubleshoot their systems. Not "something failed, go read logcat, maybe it helps, good luck". While I’m not sure whether it’s true, I think the reasoning behind this is that to the average user, a sensible error message is about as useful as "something failed, good luck".
- grishka 6y ago
  They could at least google it and find out how someone else solved the same problem. No such luck with more generalized error messages.
  - nexuist 6y ago
    An infinite loop as you described however is not really an error condition; in fact this is the premise of the Halting Problem [1] which is not solvable as far as we know. There's no way for the media provider to know if the loop will ever resolve and it may just be the case that you have an absolutely massive photo library that takes a lot of time to load. You could argue that they could add some sort of background timer that triggers an error if the provider takes too long to deliver data, but then what should that timeout be? What if the user's device is just naturally slow or the photo library is stored on some sort of external storage device (SD card maybe) with awful bandwidth? If your timeout is too low, it will prevent users from legitimately accessing their photo library; if it's too high, it ruins the point of having a timeout in the first place. In this sort of scenario the better choice rather than implementing error detection is just fixing the original problem that caused an infinite loop so users don't need to fix anything in the first place. I think the reason why debugging/resolving issues seems so complicated in modern times is in part because we already did fix most/all the "easy" issues from the past generation -- the only remaining issues are extremely hard to catch or, in the case of the Halting Problem you experienced, mathematically impossible. [1] https://en.wikipedia.org/wiki/Halting_problem https://en.wikipedia.org/wiki/Halting_problem
    - toast0 6y ago
      > In this sort of scenario the better choice rather than implementing error detection is just fixing the original problem that caused an infinite loop so users don't need to fix anything in the first place. Sure, not having the bug would be better, but I can only assume that the developers didn't intend to make the conversion loop. They failed to not have the bug then, and most likely will fail to not have bugs in the future; that's life. The solution in this case may not be to detect an error condition, but to just indicate what the software is doing. Ex a persistent notification for 'updating database schema', maybe appearing after a 5 minute timeout; if that sits around for an hour or five days or something, you can google around for it.
Polylactic_acid 6y ago
>at least show a sensible error message The only way to do this typically is to either already be aware of the issue so you can add an error (And in that case you would have just fixed the issue) Or to dump a stack trace.

read_if_gay_ 6y ago

> at least show a sensible error message so people who haven't spent ridiculous amounts of time reading the source code of your product as part of their job can troubleshoot their systems. Not "something failed, go read logcat, maybe it helps, good luck". While I’m not sure whether it’s true, I think the reasoning behind this is that to the average user, a sensible error message is about as useful as "something failed, good luck".

grishka 6y ago
They could at least google it and find out how someone else solved the same problem. No such luck with more generalized error messages.
- nexuist 6y ago
  An infinite loop as you described however is not really an error condition; in fact this is the premise of the Halting Problem [1] which is not solvable as far as we know. There's no way for the media provider to know if the loop will ever resolve and it may just be the case that you have an absolutely massive photo library that takes a lot of time to load. You could argue that they could add some sort of background timer that triggers an error if the provider takes too long to deliver data, but then what should that timeout be? What if the user's device is just naturally slow or the photo library is stored on some sort of external storage device (SD card maybe) with awful bandwidth? If your timeout is too low, it will prevent users from legitimately accessing their photo library; if it's too high, it ruins the point of having a timeout in the first place. In this sort of scenario the better choice rather than implementing error detection is just fixing the original problem that caused an infinite loop so users don't need to fix anything in the first place. I think the reason why debugging/resolving issues seems so complicated in modern times is in part because we already did fix most/all the "easy" issues from the past generation -- the only remaining issues are extremely hard to catch or, in the case of the Halting Problem you experienced, mathematically impossible. [1] https://en.wikipedia.org/wiki/Halting_problem https://en.wikipedia.org/wiki/Halting_problem
  - toast0 6y ago
    > In this sort of scenario the better choice rather than implementing error detection is just fixing the original problem that caused an infinite loop so users don't need to fix anything in the first place. Sure, not having the bug would be better, but I can only assume that the developers didn't intend to make the conversion loop. They failed to not have the bug then, and most likely will fail to not have bugs in the future; that's life. The solution in this case may not be to detect an error condition, but to just indicate what the software is doing. Ex a persistent notification for 'updating database schema', maybe appearing after a 5 minute timeout; if that sits around for an hour or five days or something, you can google around for it.

Polylactic_acid 6y ago

>at least show a sensible error message The only way to do this typically is to either already be aware of the issue so you can add an error (And in that case you would have just fixed the issue) Or to dump a stack trace.