Google Drive API file update new possible bug

Question

I have an app running on Android and using the Drive SDK java API in order to ship a copy of its internal database in an XML format into a linked Google Drive account. To update a file, here is what is done. First, a file obj. is fetched from a given known file ID (the one corresponding to the .xml residing in Google Drive):

final File tmpfile = driveService.files().get(mapperID).execute();
tmpfile.setTitle(XML_FILENAME);
tmpfile.setDescription(XML_FILEDESCRIPTION);
tmpfile.setModifiedByMeDate(new DateTime(System.currentTimeMillis()));
tmpfile.setMimeType(XML_MIMETYPE);
//Note: fileBuilder.srcFile contains a byte array of the binary content to be pushed to Drive
mediaContent = new ByteArrayContent(XML_MIMETYPE, fileBuilder.srcFile); 
File tmpResFile = driveService.files().update(mapperID,tmpfile, mediaContent).execute();

...where mapperID is an ID string fetched from a HashMap object containing a list of all file IDs of relevance inside of Google Drive, fileBuilder.srcFile is a non null byte[] object.

Until the 22nd of April 2014, at 5 AM EST, this code snipped worked perfectly and relentlessly, and updated the XML file residing in Google Drive which contains a copy of the local SQLITE database used by the app, but in a human-readable, and HTML-parsable format.

What happened at this date and hour simultaneously on all of our test sites, be them Canadian-side or US-side was the following: the modified timestamp of the file kept being correctly updated to currentTimeMillis(), but the binary content of the file stayed the same as the last valid update (i.e. within a few minutes of 2014-04-22 05:00.00 EST).

The only way we could make this issue disappear was to completely erase the file ID corresponding to that XML file, either via API, or manually by dumping the file in the trash, then clear the trash. Note that if the file is merely moved to the trash, this same issue keeps cropping up. It cannot be due to us modifying the file in the trash (or so it appears), because we tried restarting the app multiple times, and at restart (and after any Google Drive failure, for that matter), the app goes into "slow scan mode", and reconstructs the whole file hierarchy via querying Google Drive for all files in the relevant folder, with the following Q string flags in place:

trashed = false and hidden = false

And if this was really the case, then my guess is that we wouldn't see the timestamps being updated in the main folder containing the XML file, which we did see. Moreover, without throwing anything in the trash manually, we do see the file timestamp updating to currentTimeMillis() as expected, but its contents stays obsolete until we clean Drive via a full file deletion.

Right now, we are in damage control for this, but it would be nice if this was something that can be easily solved server side instead of us having to manually push client patches everywhere... And if there is a root cause to this, any patch on our end won't solve this and will only delay the inevitable.

Any ideas?