Downloads : Last access time update for NTP, duplicate infobar and notifications

chrome/browser/android/download/chrome_duplicate_download_infobar_delegate.cc

Index: chrome/browser/android/download/chrome_duplicate_download_infobar_delegate.cc
diff --git a/chrome/browser/android/download/chrome_duplicate_download_infobar_delegate.cc b/chrome/browser/android/download/chrome_duplicate_download_infobar_delegate.cc
index 4c468d902875ab486d1842874523375889c01e58..d6863b4a46df11ffc361005db61c81a1c9dc2a4c 100644
--- a/chrome/browser/android/download/chrome_duplicate_download_infobar_delegate.cc
+++ b/chrome/browser/android/download/chrome_duplicate_download_infobar_delegate.cc
@@ -114,5 +114,10 @@ bool ChromeDuplicateDownloadInfoBarDelegate::IsOffTheRecord() const {
   return is_off_the_record_;
 }
 
+std::string ChromeDuplicateDownloadInfoBarDelegate::GetDownloadGuid() const {
+  DCHECK(download_item_);

[qinmin, 2017/03/09 08:32:57]

I am wondering whether you really need to do this for duplicate infobar.
For duplicate infobar, the download hasn't started yet. The file exists on the
sdcard may belong to another download GUID, or it could be downloaded by another
software. 
So it seems wrong to associate this new GUID with that download.

[shaktisahu, 2017/03/10 02:39:59]

I see. The GUID is of the new created item whereas the file path is one of the
suggested file paths of one of the already downloaded files.
So it would be wrong to associate this GUID since it is not downloaded yet.

However I feel, we should be updating the last access time of the GUID of the
existing download which is being opened. It seems complicated to get that GUID,
so I will skip that in this patch. wdyt?

+  return download_item_->GetGuid();
+}
+
 }  // namespace android
 }  // namespace chrome