IssueTracker

Thanks for your report. However, in this case it is best that you bring this issue to the attention of your phone manufacturer. The Android Open-Source Project allows companies to bring devices to market by customizing the Android source code as they see fit. Therefore, the Android team is unable to help with issues regarding specific devices.

This isn't a device specific problem, my phones running a custom ROM built from modified source and and I am able to replicate the behaviour in android x86. For obvious reasons however I'm not willing to test this on another handset.

So you're telling me I can bust any Android device I like? With a simple date set?

And Google aren't going to do anything about it?

I jump with joy at the possibilities.

--
A Fictional iWotsit Owner with a Grudge

It's a general problem with 32-bit Linux. That's when UNIX time rolls over into negative. Not sure why that stops the device booting though, you'd think it would detect the invalid date and just set time to 0.

Good news, keith.

If you apply this ROM on your bricked Blade, it comes back to life (with the correct date!)

I just did it on my blade (which I had also locked with the 2038 bug) and it works like a charm.

http://android.modaco.com/content/zte-blade-roms-rom-customisation/338058/gen1-gen2-rom-cm-7-0-2stable-nxx-tpt-image-for-easy-install/

Are you sure the status of this issue should be declined? Second comment is correct http://code.google.com/p/android/issues/detail?id=16899#c2

Did the Project Member even read the question?

This is the Year 2038 problem, and Android are dismissing this as a hardware issue! It's so typical of bug reporting. How can enh not grasp the importance of this?

I'm not saying it's a problem with the OS rather than the phone. But he's arrogant enough to dismiss it without at least explaining to us that Android won't brick every phone set to January 19, 2038.

Can we pretty please reopen this?

I can't put a calendar entry into google calendar from my android device after 2038 without it rolling over...just hit this 'hardware' bug at the weekend..let's hope financial services don't try to do anything on an android device involving long dated fixed income securities ;-)

Ellos todavia no implementan dispositivos de 64bits pero espero lo agan antes de la fecha de expiracion

Earth will be destroyed by 19 jan 2038, so it is a hardware issue.

Lets see, create an app to change date then upload it then brick every phone... mm!

I cant understand how this problem will happen just in a certain date that will same in some years. How all the systems will fail at the same time by an error in the operating system created by the human. I tried to put that date on my samsung galaxy s4 but i cant, it only has the date up to 31/December/2036

It most likely is related to time_t type def in UNIX/Linux for 32 bit systems. The C/C++ and the underlying code that uses it needs to be fixed. In the case of my past software company the changes needed to be done were far from trivial, thus they chose not to fix it and rather have a note saying that 32 bit systems dates and operations on dates beyond the year 2037 are not supported.

Maybe it is planned obsolescence, that's why they say it is a "hardware
problem", so you have to buy a new one.
And if you see a memory leak, it is also a hardware issue, you need a one
with more RAM.

2016-02-20 1:34 GMT-03:00 <android@googlecode.com>:

Can we please stop with the conspiracies and useless information. This is a well known problem for all 32 bit systems using UNIX time (which of course includes most Android phones). As george said fixing the problem probably isn't worth it because by 2038 all phones will be 64 bit and the problem wont exist any more. The current issue is more of a DoS flaw where a malicious individual could change your phones date quite easily and brick the device.

It would be nice if there was a restriction that on systems using 32 bit timestamps that the settings app wouldn't allow setting the time to after 3035 so that it isn't this easy to brick a phone.

Also, if you plan on keeping the same phone for 20+ years good luck to you.

"Also, if you plan on keeping the same phone for 20+ years good luck to
you."

As I understand it, the Atari VCS and 2600 can fetch as much as a premium
games console if they're in good condition with a game or two.

Less so if they're bricks.

"... if you plan on keeping the same phone for 20+ years good luck to you."

My personal GSM 'phone is 11 years old and going strong. If the operator keeps GSM running as long as they promise they will [European speaking... I know North America's sunset is impending] then I conceivably may still be using it nine years from now. It's not Android, but that's not the point.

Given Android's inroads into embedded and given that many embedded systems are expected to easily run beyond 20 years, this needs some careful thought in the next, oh, let's say about five years ago.

I work with MTC/M2M/IoT solutions that are pushing two decades old and will run for another decade or so yet. 20 years is *nothing* outside the strict confines of consumers going 'ooh shiny shiny!' every few months.