Fix broken arc drawing in Camera app.

Commit f311e1983741e71e1632044bc8b2356d8688d29c introduced a recursion
abortion threshold, but missed properly handling negative values. Fixit.

Change-Id: I6776371d1567eba0a84d2e1bf702b46879e30332
Revert "ContentProvider: Avoid duplicate initialization of AsyncTask"

This change leads to soft reboots.
To reproduce:
  *) Take a screenshot
  *) Share it a few times
  *) The chooser dialog should appear but instead the system dies

E/AndroidRuntime( 4993): *** FATAL EXCEPTION IN SYSTEM PROCESS: PowerManagerService
E/AndroidRuntime( 4993): android.view.ViewRootImpl$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.
E/AndroidRuntime( 4993): 	at android.view.ViewRootImpl.checkThread(ViewRootImpl.java:6027)
E/AndroidRuntime( 4993): 	at android.view.ViewRootImpl.requestLayout(ViewRootImpl.java:820)
E/AndroidRuntime( 4993): 	at android.view.View.requestLayout(View.java:16455)
E/AndroidRuntime( 4993): 	at android.view.View.requestLayout(View.java:16455)
E/AndroidRuntime( 4993): 	at android.view.View.requestLayout(View.java:16455)
E/AndroidRuntime( 4993): 	at android.view.View.requestLayout(View.java:16455)
E/AndroidRuntime( 4993): 	at android.view.View.requestLayout(View.java:16455)
E/AndroidRuntime( 4993): 	at android.view.View.requestLayout(View.java:16455)
E/AndroidRuntime( 4993): 	at android.view.View.requestLayout(View.java:16455)
E/AndroidRuntime( 4993): 	at android.view.View.requestLayout(View.java:16455)
E/AndroidRuntime( 4993): 	at android.view.View.requestLayout(View.java:16455)
E/AndroidRuntime( 4993): 	at android.widget.AbsListView.requestLayout(AbsListView.java:1972)
E/AndroidRuntime( 4993): 	at android.widget.AdapterView$AdapterDataSetObserver.onChanged(AdapterView.java:814)
E/AndroidRuntime( 4993): 	at android.widget.AbsListView$AdapterDataSetObserver.onChanged(AbsListView.java:6482)
E/AndroidRuntime( 4993): 	at android.database.DataSetObservable.notifyChanged(DataSetObservable.java:37)
E/AndroidRuntime( 4993): 	at android.widget.BaseAdapter.notifyDataSetChanged(BaseAdapter.java:50)
E/AndroidRuntime( 4993): 	at com.android.internal.app.ResolverActivity$LoadIconTask.onPostExecute(ResolverActivity.java:756)
E/AndroidRuntime( 4993): 	at com.android.internal.app.ResolverActivity$LoadIconTask.onPostExecute(ResolverActivity.java:744)
E/AndroidRuntime( 4993): 	at android.os.AsyncTask.finish(AsyncTask.java:632)
E/AndroidRuntime( 4993): 	at android.os.AsyncTask.access$600(AsyncTask.java:177)
E/AndroidRuntime( 4993): 	at android.os.AsyncTask$InternalHandler.handleMessage(AsyncTask.java:645)
E/AndroidRuntime( 4993): 	at android.os.Handler.dispatchMessage(Handler.java:102)
E/AndroidRuntime( 4993): 	at android.os.Looper.loop(Looper.java:136)
E/AndroidRuntime( 4993): 	at android.os.HandlerThread.run(HandlerThread.java:61)

This reverts commit d22a5b851abf2a06097db51368edfda7616fc34c.

Change-Id: Ibe9c1192ec73eb46e3359da991201f6088e3a78e
Solve three memory leaks related to PatchCache

A Patch can be fairly large, holding bitmap data, but
is also frequently leaked which adds to the severity.
The feature is used in many important processes such
as Home, SystemUI and Chrome.

The following leaks are solved:

1. The Patch itself was not always freed.
PatchCache::removeDeferred() can mark patches to be
cared for by PatchCache::clearGarbage(). But
mCache.remove() would only destroy the container
and the pointer, not the Patch object itself.

2. The vertices stored in the Patch at Patch::createMesh()
would always leak. The empty/default destructor in Patch
would not properly destroy "vertices" since it's just a
pointer.

3. A BufferBlock that's added to the mFreeBlocks
in PatchCache could leak. The leak happened when a
patch later needed the entire free block, because the
object was removed from the list but never deleted
in PatchCache::setupMesh().

Change-Id: I41e60824479230b67426fc546d3dbff294c8891f
hwui: Fix a sporadic crash seen during CTS runs

 * It's possible (due to race conditions) that a patch might be
   scheduled for removal twice. Just print a warning and continue
   instead of asserting and crashing.

Change-Id: I42865f6717816a743cc49ba15b839e6c3b57ed83
advanced reboot: add soft reboot option

Adds a "Soft reboot" option which restarts zygote, as requested in JIRA
CYAN-3998

AOKP: This is based on the original commit. However we are handling the
      reboot dialog differently.

Change-Id: Ia6e5ed9b053e1c5ebd1fc55e5692858b97f7e0fc
Signed-off-by: Roman Birg <roman@cyngn.com>
Fix attribute resolution in theme lookup

[Fixes Known Issues]
1. (CM) Chrome beta crashing w/ Hexo applied and menu button is pressed.
2. (AOSP) TextAppearance - fontFamily attr is incorrect (looked up in wrong package!) when
    a string value is defined in a style, and that style is set as the app's theme.

[Terminology]
1) Theme:    is the standard android definition of a theme.
             e.g in your manifest you may set android:theme="@style/foo"
2) CM-Theme: will be a Cyanogen theme. e.g. "Hexo"

3) Block: Also called index. Can be considered the cookie or ID to lookup a package in the resources.
          When a CM-Theme is applied, block 0 is framework, block 1 is the app, and block 2 is the
          CM-Theme.

[Background]
When a value for an attribute has not been found, the last resort is to look at a theme's base value.
This is done by using theme->getAttribute(...) which will return the value. The value is
unresolved if its a reference type. The block value will also be returned.

Since the value may be a reference and therefore unresolved, a call is then made to
ResTable::resolveReference(..) to do the final resolution. As part of its input, resolveReference
takes a block as a starting point.

In the case where resolveReference(...) is asked to resolve something that is not a reference,
for example, a string type, then it will simply return the same value and block. *Important* The block
value is then saved for the next call to get an attribute value. So if this block value is wrong
it will remain incorrect.

Therefore if resolveReference is passed the wrong starting block with a string value, then the wrong
block will be returned.

[Example]
1. 0x0101009b (android:attr/textColorLink) is first attribute to be looked up.
2. textColorLink has a value of 0x01020123 which maps to theme id 0x01020111. The block for theme
is "2" so block is set to 2. The value for this attribute is put into the array.
3. 0x010103ac (android:attr/fontFamily) is the next attribute to be looked up.
4. fontFamily is found in the theme as type string. The value is 0x7b9 (1977) and newblock variable
   is set to 1 since this value is found in the app's string pool. The block variable still == 2.
5. resolveReference() is called with block=2. The function does nothing and returns block=2.
   The fontFamily thus is stored wtih value=1977 and a block value of "2" instead of "0".

Change-Id: I2b979911b1b8ffb79c4cf310ae60682c84c11fcb
Move strings of gesture unlock to correct location

To allow translate it via Crowdin.

Change-Id: I93898ab0ad865290e53a22c3bfe3d4c95efd8ceb
Signed-off-by: kecinzer <kecinzer@gmail.com>
Fix unbound prefix in latest patch

Change-Id: I3b5de1abfeafe419a8e93ae8533da2f538e9700d
Signed-off-by: kecinzer <kecinzer@gmail.com>
Import translations from crowdin.net

Change-Id: I4dff70ef4e525e142c98fa97fac7abf91123cc00
Signed-off-by: Dirk Rettschlag <dirk.rettschlag@gmail.com>
Telephony: Add TD-SCDMA network modes

1)TD-SCDMA Signal Strength support.
2)Add TD-SCDMA network type support in MobileDataStateTracker class
to identify TD-SCDMA as UMTS variant and use the relevant
kernel data stack tcp buffer sizes defined.
3) Add TD-SCDMA to the list of supported network modes.

Change-Id: I158821574484bfaf47d1660406e591e2afb3be5e
CRs-Fixed: 403258, 479310
(cherry picked from commit 2ba1b7292c6b458fb72587c1f29a5c00b70717cd)
(cherry picked from commit d58b065e7e3d84461a3c981e7a7d4673f3567ef5)
(cherry picked from commit 7844d69d3d323b3969766309c2ad5bc80411fbae)

SignalStrength: Hotfix TD-SCDMA 1 + 2

These checks need to be reviewed, they're making unwarranted assumptions
about signal value formats and possible tech combos.
This appears to work for all possible scenarios I was able to test,
but the "LTE checks" shouln't be necessary at all.

Change-Id: I889e17e79ca2b1b5fcaa393741e19bef9d3f4229
Merge branch 'kitkat' of https://github.com/AOKP/frameworks_base into kitkat