It seems to me that, from a platform design point of view, this approach is backwards.
It really shouldn't be the notifier's responsibility to check for recording. It should be the recording app's job to turn off notification and other unwanted sounds during recording. So I wonder if you could better solve your problem by directing the user to recording applications which have this feature? I still think there's value in your API idea, however. While notifiers shouldn't be expecting to adjust their behavior themselves, there's a category I'll call "audio policy managers", which try to configure the audio based on various criteria. Your proposed API would allow such applications to take recording activity into account. It's a bit ambiguous, however, just what constitutes "recording". Collecting audio data for command recognition, for example, may not want to suppress notification sounds -- it may even issue some itself. Ultimately, it's the recording app that's in the best position to make this decision. This could be done entirely within the SDK, if recording apps both adjusted the sounds themselves while recording is active, and also broadcast some agreed-upon intent to indicate the start and end of the recording activity. I'd suggest doing the broadcast before turning down the sound, to give audio policy managers a chance to relinquish any control they might try to exert. Let me propose: Action: com.sfsmart.RECORDING extra: "state" -- 0 - start, 1 - continue, 2 - end. 'continue' being entirely optional extra: "reason" -- human readable string extra: "package" -- package name of the recording app extra: "time" -- long, recording time so far in milliseconds, -1 for unknown, -1 default, -1 when sent before beginning recording extra: "duration" -- long, Expected duration in milliseconds. -1 for unknown, -1 default Sending 'continue' may not be viable if running broadcast receivers causes audio overruns. Compliant recorders would: 1) Broadcast the above intent 2) Adjust the volume as desired 3) Begin recording. (If low latency is required, you can begin earlier) 4) End recording 5) Restore the volume to its original values 6) Broadcast the above intent. Of course, no compliant recorders exist, currently, though if this sounds interesting, I could create one. Thoughts? On Mar 6, 1:30 am, ani <[email protected]> wrote: > I am closing this thread as i understood your point. > However don't you think i deserve some pointers to resolve this > problem(There is a use case when user doesn't want the notifications > sound to be recorded.As of now if recording is going on and > notifications comes,it is also getting recorded.Which i don't want). > Hoping for a reply. > > Thanks Google and Mark for your valuable time. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
