Library projects in the SDK are built using --non-constant-id
to generate a temporary R.java class.
When the library is packaged with the application to generate an
apk, the R class is recreated with the proper IDs due to all the
resources coming from the app and all the libraries.
However for large apps with many libraries (each with their own
R class in their package), this means a lot of unnecessary IDs:
all R classes contains all the IDs including for resources from
by projects they don't have access through the dependency graph.
For really large apps (X,000 resources), with lots of libraries
(10+), this can generate tens of thousands of resources, which
can trigger dalvik's limit of 65K fields and methods per dex
files.
This changes lets aapt generate not only the R class but a simple
text file containing the list of all those IDs so that it is
easier to parse back. The SDK build system will not ask aapt
to generate the R class of the libraries (through the
--extra-packages option), instead it will then read this
file to know what IDs are needed for each library and generate
a much smaller R class for each library (using the same text
file output from compiling all the resources to get the final
integer value).
Chery-picked from f5de650ff1e161ea135c828e43515895343d2c0f
Change-Id: I0e08ceb6e4ceb3feb169ce17df21dd35a2505e7f
JB has introduced LockSettingsService. When the phone is
upgrading from ICS, that used another way to store lock
settings, the LockSettingsService needs to import these
settings to store in its database. This happens when the
systemReady() method of this class is called by SystemServer.
The problem resides in the fact that the
DevicePolicyManagerService actually needs to access the
LockSettingsService during its systemReady() initialization,
causing invalid values to be read by it which propagates and
ends up causing a invalid return in the method
isActivePasswordSufficient.
If user had a Google corporate account that enforces password
related policies through Google Apps Device Policy (GADP) app
in ICS, when he upgrades to JB, the GADP will throw a
notification saying that the password doesn't meet the required
policies and needs to be changed, incorrectly, since it wasn't
touched during upgrade.
This fix initializes the LockSettingsService before the
DevicePolicyManagerService, which is the correct way since
the latter uses the first in its initialization. This prevents
this issue to happen, and probably future issues, depending
on the way that LockSettingsService evolves.
Change-Id: I3d4334a8b728f0ad9ae744cece430d15af25a0b7
* commit 'edf0ba6e1b6de8f43880267862e43ee461901c25':
cherrypick from jb-dev Change-Id: Ib0ec41960017725db3fbedb2b62350dc8f8d3468 new Google Play badges and some updates to corresponding pages
* commit '0cc7398ab9196cf3ae8075f8e7bd055a900ebb2e':
dashboard update for 9/4 switch to simplified pie charts: codenames for platforms and separate size and density charts
* commit '442040208cba3be464d7a180283d72d9ec074def':
cherrypick from jb-dev Change-Id: Ib0ec41960017725db3fbedb2b62350dc8f8d3468 new Google Play badges and some updates to corresponding pages
* commit 'd46023d2081c995b2ec61b48b79f2077dfdb36a2':
dashboard update for 9/4 switch to simplified pie charts: codenames for platforms and separate size and density charts
