Is there any distinction between the key functionality of Android controls: Action bar vs. Toolbar, Spinner vs. Dropdown. To me they seem to be the same and I wonder if there is a reason of introducing new terminology for the controls that already existed.
Spinners and Pickers are effectively attractive drop-down lists, but they both have a slightly different form.
A spinner is more streamlined, and can be found within the action bar to quickly change data sets or views(email account, calendar view, etc).
A picker takes up more space, and is more like an analog radio dial, in my mind. It's great for step-wise data like Times, Dates, or other gradually increasing/decreasing numbers.
I do admit to being a little confused about the names, since you pick from a spinner and spin a picker, but I try not to ponder that too much.
I'm not sure if anything in Android is called a toolbar, but the action bar tends to serve this purpose in most apps. The main functions sit on the action bar, with the rest overflowing when needed. The action bar can change its buttons depending on context, which makes it behave like a toolbar that only shows up when you need it. For instance, when you select an email, you get options to Archive, Delete, Label, Mark as unread, Star, etc.
@Karen covers the Spinner vs Picker question. Regarding the ActionBar vs Toolbar question:
A Toolbar is a generalization of action bars for use within application layouts.
ActionBar was the first design introduced in Android v3.0 (Honeycomb). It was liked, but difficult to extend beyond the specific use cases Google initially planned for. Later on, Google accepted that the implementation of the
ActionBar was a little rigid for what developers wanted to do with it. Especially when the Material guidelines were released.
That brings us to the Material design that was released with Android v5.0 (Lollipop). Due to the increasingly robust uses they wanted the
ActionBar to perform, they needed to make something more flexible. But backwards compatibility forced the following workaround: Keep the
ActionBar concept and related
Activity methods, but copy most of its functionality into another class called
Toolbar that is implemented more like a regular
View. Now you create a
Toolbar and assign it to the
ActionBar's spot, replacing the old, limited
The benefit is that this new
Toolbar class behaves more like a regular
View while still including many of the built-in behaviors of the
ActionBar. The new
Toolbar can be placed anywhere in an activity/fragment layout, can contain other custom views and layouts, interact with parent views that contain the
Toolbar, and more. The
ActionBar wasn't nearly as flexible.
Nowadays, everyone uses the
Toolbar class then assigns it to the
ActionBar of the
Activity. (The details of how are easily found in the Android Developer guides.)
In fact, the Material design guidelines pretty much require this since the Toolbar is required to interact with scrolling content and other features that the
ActionBar can not offer by itself.
For further reading, see the Android Toolbar developer documentation