Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 0605956e authored by Matías Hernández's avatar Matías Hernández
Browse files

Update API documentation about snoozing and bypassing channels 

Fixes: 359895641
Test: N/A
Flag: EXEMPT Javadoc
Change-Id: I3a0d7288abdff2cfb403576ec86dcff3ef95cc5e
parent e01576ea

core/java/android/app/NotificationChannel.java

+7 −2
Original line number Diff line number Diff line
@@ -753,9 +753,14 @@ public final class NotificationChannel implements Parcelable { 


    /**

     * Sets whether or not notifications posted to this channel can interrupt the user in

     * {@link android.app.NotificationManager.Policy#INTERRUPTION_FILTER_PRIORITY} mode.

     * {@link android.app.NotificationManager#INTERRUPTION_FILTER_PRIORITY} mode.

     *

     * Only modifiable by the system and notification ranker.

     * <p>Apps with Do Not Disturb policy access (see

     * {@link NotificationManager#isNotificationPolicyAccessGranted()}) can set up their own

     * channels this way, but only if the channel hasn't been updated by the user since its

     * creation.

     *

     * <p>Otherwise, this value is only modifiable by the system and the notification ranker.

     */

    public void setBypassDnd(boolean bypassDnd) {

        this.mBypassDnd = bypassDnd;

core/java/android/app/NotificationManager.java

+30 −4
Original line number Diff line number Diff line
@@ -1440,10 +1440,36 @@ public class NotificationManager { 
     * Informs the notification manager that the state of an {@link AutomaticZenRule} has changed.

     * Use this method to put the system into Do Not Disturb mode or request that it exits Do Not

     * Disturb mode. The calling app must own the provided {@link android.app.AutomaticZenRule}.

     * <p>

     *     This method can be used in conjunction with or as a replacement to

     *

     * <p>This method can be used in conjunction with or as a replacement to

     * {@link android.service.notification.ConditionProviderService#notifyCondition(Condition)}.

     * </p>

     *

     * <p>The condition change may be ignored if the user has activated or deactivated the rule

     * manually -- the user can "override" the rule <em>this time</em>, with the rule resuming its

     * normal operation for the next cycle. When this has happened, the supplied condition will be

     * applied only once the automatic state is in agreement with the user-provided state. For

     * example, assume that the {@link AutomaticZenRule} corresponds to a "Driving Mode" with

     * automatic driving detection.

     *

     * <ol>

     *     <li>App detects driving and notifies the system that the rule should be active, calling

     *     this method with a {@link Condition} with {@link Condition#STATE_TRUE}).

     *     <li>User deactivates ("snoozes") the rule for some reason. This overrides the

     *     app-provided condition state.

     *     <li>App is still detecting driving, so again calls with {@link Condition#STATE_TRUE}.

     *     This is ignored by the system, as the user override prevails.

     *     <li>Some time later, the app detects that driving stopped, so the rule should be

     *     inactive, and calls with {@link Condition#STATE_FALSE}). This doesn't change the actual

     *     rule state (it was already inactive due to the user's override), but clears the override.

     *     <li>Some time later, the app detects that driving has started again, and notifies that

     *     the rule should be active (calling with {@link Condition#STATE_TRUE} again). The rule is

     *     activated.

     * </ol>

     *

     * <p>Note that the behavior at step #3 is different if the app also specifies

     * {@link Condition#SOURCE_USER_ACTION} as the {@link Condition#source} -- rule state updates

     * coming from user actions are not ignored.

     *

     * @param id The id of the rule whose state should change

     * @param condition The new state of this rule

     */