* commit '0034beab72d6574de5009e5947729a2bfd17d66e':
implement new organization for Training classes This also moves a few of the documents from API Guides > Best Practices into the new courses for best practices. This is also dependent on CL Ieac8a97a8d6fda41a3682241901150cfe16afc4d which generates the list of classes/lessons on each course landing page.
* commit '22cc2764cc74e52888b043e0c6371594305bb5e9':
implement new organization for Training classes This also moves a few of the documents from API Guides > Best Practices into the new courses for best practices. This is also dependent on CL Ieac8a97a8d6fda41a3682241901150cfe16afc4d which generates the list of classes/lessons on each course landing page.
This also moves a few of the documents from API Guides > Best Practices
into the new courses for best practices.
This is also dependent on CL Ieac8a97a8d6fda41a3682241901150cfe16afc4d
which generates the list of classes/lessons on each course landing page.
Change-Id: I8132f72f78d844c3b035c7aa269ad3b88a25d02a
- keep the Error Drawable infos into the Drawables cache
- reset left/right Drawable state before resolving where to put the Error Drawable
- get the mirrored Drawable for the Error popup background
- set the Error popup position depending on the layout direction (so that the "triangle"
of the background is pointing to the middle of the Error icon)
One restriction: we load the Error popup background Drawable corresponding to the layout
direction of the System Locale. So if you set the Layout direction on a TextView (or
an EditText) to RTL and set an error to it when you are in a RTL System Locale, then you
see that the background "triangle" is not pointing to the Error icon. This is working as
intended as the AssetManager load the Drawable resource depending on the configuration
which is in that case the RTL one thus loading the RTL version of the background (and not
the LTR one).
Thus there can be a discrepancy between the "layout direction" of the TextView
and the one from the Error popup background. This would happen only thru using the SDK and
not in a normal case when running an App.
Change-Id: I91bbfbe46ac20efe0e585c5d4c766db23b5c709d
Rely on behavior of already-released CountDownLatch instead of
clearing the reference.
Bug: 7290521
Change-Id: I787e673b97d18be412d5b37e279fbf1275b49151
(This relates to the new vibration fallback behavior, where
notifications that expect to make a sound should always
vibrate in vibrate mode. We should not vibrate if the
notification's sound is silent, but we should also not
vibrate if the notification uses the default sound and the
default is silent.)
Bug: 7537077
Change-Id: I08e149c8c00ef2d2f61e418d88a086cb5e9cf241
- When notifications vibrate as a fallback (that is,
because they want to play a sound but the device is in
vibrate mode), this no longer requires the VIBRATE
permission.
- As a bonus, if your notifications use DEFAULT_VIBRATE,
you don't need the VIBRATE permission either.
- If you specify a custom vibration pattern, you'll still
need the VIBRATE permission for that.
- Notifications vibrating in fallback mode use a different
vibration pattern.
- The DEFAULT_VIBRATE and fallback vibrate patterns are now
specified in config.xml.
Bug: 7531442
Change-Id: I7a2d8413d1becc53b9d31f0d1abbc2acc3f650c6
