7
JS96
3y

For what fucking reason the ability to set the date and time programatically has been blocked on Android?!
Why you can create fucking invisible apps that work in the background, mine cryptos, steal your data but they decided that something like that is considered dangerous?

Can anyone give me a logical explanation?

P.S.
There are cases (big pharma companies) where the users don't have access to internet nor a ntp server is available on the local network, so the ability for an app to get the time of a sql server and set it in runtime is crucial, expecially when the user, for security reasons, can't have access to the device settings and change it by himself.
"System apps" can do it, but you would have to change the firmware of a device to sideload an external "System app" and in that case it would lose the warranty.

So, yeah, fucking Google assholes, there are cases where your dumb decisions make the others struggle every other day.
Give more power to third party developers, dumb motherfuckers.
It's not that difficult to ask the user, once, to give the SET_TIME permission.
It was possible in the past...

P.S.2
Windows Mobile 6.5 was a masterpiece for business.
It still could be, just mount better CPUs on PDAs and extend the support. But no, "Android is the future". What a fucking bad future.

Comments
  • 3
    I guess changing time could fuck with encryption, signing and stuff
  • 3
    @ScriptCoded But also having access to storage could led to data lose without the knowledge of the user, etc..

    I should have the ability to choose if I want to give this permission or not.
    And if it really could have dangerous consequencies I shouldn't be able to change it manually in the settings, but I can.

    The problem is that a device in standby or when turned off is able to lose a few seconds every day. So it's a matter of a few weeks and the difference becomes 1 minute, which for some apps isn't acceptable.
    I know my case is very rare and specific, but imagine an app that you can use in particular places where you don't have an internet access, and you can't put "GETDATE()" in every SQL query because after the login, when the app is sure the time and date is synced, you can use an offline mode (big pharma rooms without wifi) that stores data in a local db and have to sync it later when the network is available again.
    You can't have a time difference for this sensible data.
  • 0
    @JS96 external storage is also blocked in android behind a permission.
  • 1
    @iiii which you can ask for... you can't ask for "SET_TIME" permission because it's only available for system apps... that's the issue.
  • 1
    Solution 1 : Somebody have to install the app since the setting are blocked. Can that person set it to correct timezone?

    Solution 2 : Make the app non-time dependent.

    Solution 3 : Even if you cannot set the timezone , you can still get the timezone (even if it not the one you wanted) , right ? Convert the incorrect timezone date into UTC or something that you can easily translate in server.
  • 0
    @mr-user
    The problem is not the timezone, but the time itself...
    If you have a device without access to an ntp server (local or online, e.g. time.google.com) the device will start to lose a few seconds every day, it will never be 100% synced with the real time, even if it has been set correctly at the beginning.
    It's something you never notice because your phone is always connected and syncs the date and time constantly.

    The second problem is the app needs to record data that are required to have a time and date (e.g. Audit Trail, login/logout logs) that must be uploaded on a server from different devices, so they have to be reliable and not device dependent.

    If user A did something at 2:00, you can't have a record in the database that says he did it at 2:01, or 2:10...

    P.S.
    Talking about the first solution, there is an admin that can do it, and in fact this is the issue... the users have to go to another building and give the PDAs to the admin to change it manually very often. :\
  • 0
    Also no, you can't create arbitrary background consuming apps any more.

    Yes, you can schedule wakeups, but usually only for a few seconds. Or you can have a constant notification.
    For unlimited background access, a permission is required, and a developer as to write a reason or the app is denied to be uploaded into the Play Store. Also, many OEMs break unlimited background services as well.

    Anyway, setting the system time is security critical, as certificate checks require a correct time. Users usually do not know these implications. Additionally, an innocent but faulty app may interrupt other apps as well.
    Besides the scenario (Google NTP not reachable, no GPS, no time service by cellular network, no access to settings but an app can contact its own time server) being quite unlikely, the app can just regularly fetch the correct time and apply the difference to timestamps returned by the system clock.
  • 1
    You don’t fuck with time. Universe might split.
  • 0
    Not sure if i understand the situation completely correct.

    Do you have an app that you/your company writes that needs the correct time? This app can get the correct time from your server but can't change the system time?

    Why do you need to set the system time? Can you not keep the correct time in the app, which you get from the server, and ignore the system time?
  • 0
    @JS96 just storing a difference should work, right? You can even use the difference between current and last sync difference to guess the drift and correct timestamps before syncing.

    Also, can you not just run your own local ntp server? That would be the most sensible solution.
  • 1
    Just installing a system app won't void your warranty, don't be silly. Fixing problems that could be caused by such activity just isn't part of the warranty.
Add Comment