This article was first published on the public account AndroidKotlin, welcome to search AndroidKotlin follow me ~
I believe you have all seen the news recently, “Netizens claim to have been remotely deleted photos by Pinduoduo APP”.
Simply describe the process of the event, a net friend, from the spell of the App that invite a new user, you can directly cash 100 yuan, after the successful invited, found that giving is a random amount, not 100 yuan cash this matter, after talking to customer service, send the invitation to a new user, can be directly withdraw 100 yuan of screenshots, After sending it, he received a notification from Vivo’s mobile phone system indicating that the photo in the camera had been deleted, so he suspected pinduoduo of remotely controlling the phone and deleting the picture.
As an Android engineer, I found this problem interesting, so I decided to test whether Pinduoduo did delete users’ photos.
First of all, as we all know, almost all Android apps acquire the user’s read and write permission of storage space, which is used to save and read relevant data. Therefore, from a technical point of view, as long as the user obtains this permission, any file in the public storage space can be deleted.
As developers, we all know, public storage space of arbitrary data deleted users, this is absolutely unreasonable behavior, but there is one point to note is, when we develop the App, will at some point in the user data generated in this App save to public storage space, such as pictures, documents, or other media resource file.
By observing the pinduoduo chat page, we can know that there are two ways to send pictures
1. Click Photo Send (that is, click the photo button and select the phone’s local photo send)
2. Click “Shoot and send” (take a photo and send it through the photo function of Pinduoduo)
So in this case, there’s one thing we need to be clear about
Did the deleted screenshots originally exist on this phone, or did the user use this feature to take screenshots on another phone while chatting with customer service?
If the picture was sent in the first way, then the picture was deleted, which is obviously a problem for PINDUoduo.
To turn the video again, I found that send pictures is not the original screenshots, but photographs, of course, this also can’t say definitely is the spell, many users use chat in camera, may also is to use mobile phone took another phone screenshots, and then send pictures, of course it’s like the first kind of way to send.
But this problem, as long as the parties know what is going on.
Let’s discuss the second method here. If the user uses the Shoot button on the chat page, takes a screenshot and sends it, will the picture be deleted?
I took a photo with the photo function of pinduoduo chat page, but before I clicked the “finish” button to send, I checked the storage space of the phone, and found that the photo had been saved under the file directory DCIM/Pindd/image/16.
When I hit send, the photo was still there, not deleted.
So according to vivo’s system notification, an image was deleted. What happened?
After watching the video again, I found that there was an obvious red mark on 👆 in the picture I sent. Combined with the page of the photo I took above, we can find that Pinduoduo provides picture editing function after taking photos.
So I guess it was a screenshot taken on the app’s chat page, redlined by post-shot editing, and sent.
Normal logic says that only one image should be kept from the moment it is taken to the moment it is sent, which is fine.
According to the operation logic I guessed above, in fact, I took the original picture and saved it, edited the original picture to generate a new edited picture, and then sent the edited picture, so the original picture here actually belongs to a temporary picture, so it is no problem to delete the original picture and keep the edited picture.
See here, make the development of the students should be very familiar with this operation, in most photo editing business scenarios, we are dealing with, because of the original image is equivalent to a temporary file, the final edited file is the final file, the temporary file is no sense for the user and meaningless, so delete is normal behavior.
So what went wrong?
The problem occurred when Pinduoduo deleted the original picture, and Vivo’s phone detected that the picture was deleted. Why did vivo phone detect the picture being deleted?
Do you remember the address where pinduoduo saved the pictures? DCIM/Pindd/image/16 is under DCIM, which is equivalent to the public album directory of the system. If you save or delete any image in this directory, the system will be notified that the album has been changed. Therefore, when Pindoduo deleted the temporary file, a notification of image deletion appeared in Vivo.
The real problem is that Pinduoduo should not save temporary picture files in DCIM. I believe this problem is not limited to Pinduoduo App, and many apps may have this problem. In the final analysis, it is the non-standard use of Android file directories. It should be stored in the App’s private cache directory, as specified in the Android development documentation. 👇
According to the latest statement on Pinduoduo’s official micro blog, my guess is correct.
The correct way to do this is simply to place the temporary files in the internal store getCacheDir() or the external store getExternalCacheDir(), and when all the logic is done, synchronize the images to the public album folder.
Compared with Duo Duo, wechat chat page also has the scene of photo editing and sending. In contrast, wechat, only after the last step of sending and clicking, the picture will be saved in the mobile phone user visible picture folder, as for the temporary file in the middle, users can not perceive.
When I wrote this article, I found that pinduoduo App would not delete the original picture after editing the picture, probably through the method of hot repair, temporarily processing the logic here.
Seems to solve the problem, but fundamentally, or the use of Android file directory is not standard problem, hot repair is also a palliative solution, I hope pinduo can completely solve this problem after it.
In addition, Google has released a new specification for Android 10 Scoped Storage, which is not strictly implemented on Android 10, but must be adapted on Android 11. So for those of you reading this article, Also hope that you can check this part of the code, as soon as possible to do adaptation.
Now looking back at the problem, do you think it’s a serious problem?
From a technical point of view, is really a small problem, but from the Angle of the incident fermentation, it is a big problem, any small problems are likely to have serious consequences, so write code is needed to keep the rigorous, is not just a simple finish requirements, more to think about it, it’s really no problem?
Again, no matter your skill level, check out the Android documentation every now and then and you’ll find something you missed or misunderstood in the past.
Thanks for reading, and I’ll see you next time.