1

Just want to register to video/photo taken events.

Hopefully, but not a must, the event will be triggered when the operation have finished, so I won't process half photos or half taken videos.

Already tried:

fileObserver = new FileObserver(dcimDir, FileObserver.ALL_EVENTS)

I see the events when traversing using a file manager app but not when a picture is taken nor when copying.

Ideas?

tshepang
  • 12,111
  • 21
  • 91
  • 136
AlikElzin-kilaka
  • 34,335
  • 35
  • 194
  • 277
  • Perhaps I need to listen (register) to each and every folder within the dcim folder because the file events trigger only the direct parent and not some grandparent - even though in the documentation they say that the listener is recursive. – AlikElzin-kilaka Sep 01 '11 at 19:32
  • Another option may be to use some DB listener. Anyone familiar with that? – AlikElzin-kilaka Sep 01 '11 at 19:32
  • Possible duplicate? http://stackoverflow.com/questions/4571461/broadcast-receiver-wont-receive-camera-event although that answer may not be the best solution. – Steve Blackwell Sep 01 '11 at 19:42
  • Steven, this is a whole different question with perhaps similar solution. I'm asking for photos taken listening techniques he's contemplating on why the broadcast receiver doesn't work. – AlikElzin-kilaka Sep 01 '11 at 20:23

2 Answers2

1

Found a way by registering to all sub directories of dcim (except the ones that start with a period):

new FileObserver(dcimDir.toString(), FileObserver.CLOSE_WRITE)

The reason I need to register to all of them is because different phones put picutes and videos in different folders - at least they are all under DCIM.

The reason the event is 'CLOSE_WRITE' is because I want to trigger after the photo/video is complete, so I won't process only half of the photo/video.

AlikElzin-kilaka
  • 34,335
  • 35
  • 194
  • 277
  • 1
    The major downside of this app is that it requires the app that listens to always keep running, thus will not work if the system kills it. – AlikElzin-kilaka Jul 16 '12 at 15:10
  • Not really true. If you register the observer in service started as sticky (Service.START_STICKY) or even if you set it as foreground service (with Service.startForeground()), the system won't kill it and if so, it'll restart it ASAP. – d.aemon Jul 04 '16 at 15:21
  • @d.aemon START_STICKY won't help on Huawai Nova3 device. But I believe foreground service will do the job. Not sure if it consumes much battery this way. – g g Jul 28 '22 at 02:52
  • @g-g I believe this whole conversation is now obsolete as today there are more system measures to conserve battery life, probably even security constraints. And also there might be new API classes that offer what was originally intended. I would try another search here. On second click I have found feasible answer here https://stackoverflow.com/questions/40025585/android-get-recently-added-media-in-android-device-similarly-to-file-manager – d.aemon Jul 29 '22 at 09:01
  • @d.aemon Thanks a lot. Yes due to Android policy changes on newer versions, some solution won't work any longer. The link you found I also read and that method stopped working since Android O. For what I learned so far, either using forground service which may be anoying, or using broadcast receiver to receive ACTION_MEDIA_SCANNER_SCAN_FILE event which may be less efficient. – g g Jul 30 '22 at 09:11
0

There is another way: ContentProvider

See another SE thread for more info: Android -- How does Google+ instant upload work?

Community
  • 1
  • 1
AlikElzin-kilaka
  • 34,335
  • 35
  • 194
  • 277
  • The major downside of this app is that it requires the app that listens to always keep running, thus will not work if the system kills it. – AlikElzin-kilaka Jul 16 '12 at 15:10
  • Not really true. If you register the observer in service started as sticky (Service.START_STICKY) or even if you set it as foreground service (with Service.startForeground()), the system won't kill it and if so, it'll restart it ASAP. – d.aemon Jul 04 '16 at 15:21