Change-Id: I4036c924958221cbc644724f8eb01c5de3cd7954

If the id is negative, it is not from Resource.
Passing the negative value to getResourcePackageName makes AssetManager dump unnecessary warning logs.
It is reasonable not to get package/type/entry information for the negative id.

The warning logs :
W/ResourceType( 3711): No known package when getting name for resource
number 0x9b010100

Change-Id: Ic89acb4f32205ba5a2fdac61dc14b00ccf251148

This has been moved into its own repository at

//system/tools/aidl

Test: Built aosp_arm-eng from scratch.
Bug: 23691099

Change-Id: Ic45d55682b9dcafe894efe0a6317792f9c1236c6

After boot when status bar donot have any notification, the
overscroll is rubberbanded , changes have been done to fix
this and make the behaviour consistent with other scenarios.

In NotificationStackScrollLayout when there is no childview
present at the touch coordinate, initialization of some
variable was not done which was resulting into overscroll
being rubberbanded.

Usecase of the issue:
1. Reboot the phone.
2. Make sure that no notification is present
3. Pull the status bar.
4. Now pull the "No notifactions" view ,the overscroll
   is rubberbanded
5. Get some notifications, pull the status bar and then
   the notifications, the overscroll is not rubberbanded
6. Remove all the notifications, now pull the statusbar
   and then pull "No notifications" view the overscroll is not
   rubberbanded.

Change-Id: I06d4f0e3d6ed980744be21b9fd7ed307dca69ca3
Signed-off-by: Jayasri bhattacharyya <jayabhatt@codeaurora.org>

This reverts commit 2535cae0.

Change-Id: I373844b6a0f429e88d6bcc1cdd5ac62325da55b3

This is attempting to fix build breakage caused by redefining the isatty stub
for win32.

Change-Id: I5f854934cb9d2b2981f6349045e85d9ad737aa77
Signed-off-by: Casey Dahlin <sadmac@google.com>

Bug: 22926131

This is the documentation update corresponding to our new named
structures for RS object types.

Change-Id: I282ce78192da7c9f68951ce05100819a306694f0

Change-Id: I1802f60a4dac45ddee8cd5715a73c77e4371d7e8
Signed-off-by: Casey Dahlin <sadmac@google.com>

We have to step up to a GLR parser to do this without exceptions (for no
reason other than Bison happens to use exceptions for the LALR(1) template and
not for the GLR one), but this should let us smooth out integration going
forward.

Change-Id: Iff44662914b4a65dfa5612d07c3a1ede07e6e4a9
Signed-off-by: Casey Dahlin <sadmac@google.com>

We're flipping Flex/Bison in to reentrant mode, cutting down on global
variables, and exposing a more C++-like interface earlier. This is the first
phase. There's still a couple of weird hacks to deal with the previous code's
reckless disregard for scope sanity, but the outline of things to come is
starting to appear, and this CL really doesn't need to get any bigger.

Change-Id: Ife2d70db026d7ab1319bdf6c586959315666d0bb
Signed-off-by: Casey Dahlin <sadmac@google.com>

Change-Id: Iea788eb81c24dcaceeea35a6b004416caa1cf9c6

This includes FP16 and the rs_kernel_context object.

Change-Id: If5574bba85060e2bfe6c4d8f2b3cc1b49827a05a

Change-Id: I0d891ab08e61df7422fb0aea50a4c31196792189
Signed-off-by: Young-Ho Cha <ganadist@gmail.com>

Many classes in graphics/java and elsewhere deallocate native memory
in a finalizer on the assumption that instance methods can no longer
be called once the finalizer has been called.  This is incorrect if
the object can be used, possibly indirectly, from another finalizer,
possibly one in the application.

This is the initial installment of a patch to cause such post-finalization
uses to at least see a null pointer rather than causing memory corruption
by accessing deallocated native memory. This should make it possible to
identify and fix such finalization ordering issues.

There are more graphics classes that need this treatment, and probably
many more in other subsystems.

This solution is < 100% effective if finalizers can be invoked
concurrently.  We currently promise that they aren't.

(In my opinion, the real cause here is a language spec bug.  But that ship
has sailed.)

Bug: 18178237
Change-Id: I844cf1e0fbb190407389c4f8e8f072752cca6198

Bug: 23566667
Change-Id: I030733ffd2b43a0ea74b0fd5f34a0d13ef8dcf7c

When a GradientDrawable is loaded from scratch, initializeWithState()
is called with mColors == null. This sets mFillPaint's color to
0x00000000 -- transparent. mColors is then properly set in inflate(),
but mFillPaint is not updated there. It will be updated eventually
through a mutate() or ensureValidRect() call, but that's sometimes too
late.

In our case, a wrapping StateListDrawable called getOpacity(), and
since it caches the result, it never got updated.

This doesn't cause any problems on preloaded GradientDrawables, since
the new GradientDrawable created when fetching a preload will call
initializeWithState() in its constructor, fixing the GradientState.

Change-Id: Ic8caa7c6a7c1d4dae5ff31ae943831bd2e014f79

BUG: 22207144
Change-Id: I2b15bb7c4055a1ad589b433d4f253868813ab311

Bug: 23718807
Test: Re-ran make. Confirmed code was not linked.
Change-Id: If065b9287ed70b9e380281cae42f89bd5f1ffb06
Signed-off-by: Casey Dahlin <sadmac@google.com>

AIDL previously supported "rpc" and "flatten" types, which are not used
anywhere in the Android tree. This patch removes them, which significantly cuts
down code and complexity.

Bug: 23517584
Test: Rebuilt AOSP tree against new version
Change-Id: I6cf38d43c1ce109ffca987cc14520945aa22431f
Signed-off-by: Casey Dahlin <sadmac@google.com>

This test sets up an artificial hierarchy of .aidl files, then
checks that the generated code contains a substring that we
know to be correct.  This isn't a very good unittest, but it does
validate that the whole flow works start to finish.

Bug: 23516947
Test: compiles, unit tests pass.

Change-Id: I931b7659731b05440040623e12596669604cef3a