Settings: Fix devloper options FC and remove all bug report options

This change: https://gerrit.slimroms.net/#/c/18820/

removed it just in the xml which is a pretty bad idea if java code
still assumes it is there.

Due that we will never need it we remove the code completely.

As well remove bug report in power menu option.

Change-Id: I234dee3a19639f89b5a7b5295ca408142e4223dc
Settings: ADB_NOTIFY moved to Global

Change-Id: I6fc6d8ab8c7a4dd7c5f441b9dfa9166822051e82
Settings: add back button in actionbar on Status settings

for more consistence. We add it as drawable due that we still have 3 other
places in settings where it is missing.

We will change later....after that we should have worked every inconsistence out.

Change-Id: If21d03b04d2356fa78349baa8ff2fb3b008dacbf
Settings: Update AppNotificationSettings if user resumes

Right now if a user resumes this activty (eg from recents) and did change in the
mean time settings which effects the visibility of preferences in AppNotificationSettings
(eg were removed) it does not get updated.

Fix it with simply reloading the content on onResume and decide to show the entries
on the current user settings situation.

Change-Id: I0b16ebf35604fdca1611f026c9b609427f3060c8
Settings: Do not allow to access quick settings on secure lockscreen - option (2/2)

We have a lot security guys as user due of using the phones as business phones...that
said a lot complains go into the direction of google how it is possible to have
access to quick settings on a secure lockscreen which is absolutely understandable
due that you are able to control Wifi BT AirplaneMode data etc.

This patch takes care on this problem and adds an option to control this behaviour.

ATTENTION: Due that this is really an UX derp for an average user this feature is
enabled by default now. User need to disable it explicit in settings to get on secure
locksreen the original android behaviour back.

PS2:
- fix derp

Change-Id: Iac8c181767a16d3d198672d16901670984b58f48
Prevent factory reset for short passwords in CryptKeeper

Since patterns and passwords can't be shorter than 4
elements, we shouldn't count them against attempts to unlock
the device.  If we do, we risk resetting the device
due to stray input.

Bug: 18211475
Bug: 18273380

Conflicts:
        src/com/android/settings/CryptKeeper.java

Conflicts:
        src/com/android/settings/CryptKeeper.java

Change-Id: Ib329cd3383471483cda68bfac4278b17d0c09c57
packages: settings: CryptKeeper: Disable FDE if PFE activated

Don't allow Full-Disk-Encryption (FDE) after Per-File-Encryption (PFE)

Change-Id: I5ed46d4362f6536a6cf526aa5bf4bac4610c47b6
Settings: fix a couple of multiuser bugs

- show interface settings
- hide media scan on boot behaviour
- show privacy guard

for other users

Change-Id: I2b488f69b820f289d7ddb04e5171637b355dc5cf
Return: Smart Pulldown [2/2]

Change-Id: Iba759e421b8cbb02fadaa6540aae7b7a74764293
Settings: Add proximity wake option

Ports and combines:

http://review.cyanogenmod.org/#/c/66658/
Settings : Add preference for proximity wake

http://review.cyanogenmod.org/#/c/69347/
Proximity Wake-Up : adjust strings

http://review.cyanogenmod.org/#/c/69803/
Settings : Make proximity opt-in

Change-Id: Iea0853eccf764438c7aaac76afd13c364fcea0ec
bluetooth: Don't crash when the local adapter is not set

In devices where bluetooth is not working (like the emulator or devices
in development), the bluetooth Settings crashes when closing the activity.

Most of the code checks for the nullability of the local adapter except
for this particular piece. This is usually not a worry for production
devices and I wouldn't usually worry about this but since the rest of the
code performs the nullability check it seems silly to crash onPause.

Change-Id: I7c1d3b43969b516336be770957008ef2054d312f