scan.cpp gets sys/stat.h inherited from
private/android_filesystem_config.h it should
not rely on this in the future. The intent is
to move fs_config function into libcutils and
thus deprecate any need for sys/stat.h in this
include file.
Bug: 19908228
Change-Id: If547e86513b06c536972138ae571c3d9c714ffe9
app_main.c gets sys/stat.h inherited from
private/android_filesystem_config.h it should
not rely on this in the future. The intent is
to move fs_config function into libcutils and
thus deprecate any need for sys/stat.h in this
include file.
Bug: 19908228
Change-Id: I477b825e582742113f849aaa1df50c41e496b6f6
frameworks/testing/uiautomator -> frameworks/base/cmds/uiautomator
(samples, utils sub folders exlcuded)
frameworks/testing/uiautomator/utils -> frameworks/base/tests/utils
no source files changed, only one line makefile update (for
UI Automator API check)
Bug: 18708851
Change-Id: I396bd386d3d55a52df18af183685daf80caa9f73
Use LOCAL_WHOLE_STATIC_LIBRARIES to instruct static linker
to export symbols from the static library.
(cherry picked from commit 5ba317cee071b718a163ab9acf2b6b4f6a337b39)
Bug: 18701723
Change-Id: Id9b567a1529574eab2225777f1f2a5ea10e540ad
Adjust format strings to not produce Clang warnings in both 32-bit and
64-bit builds
Change-Id: I76c29d8d5d0fb4b5e9d9518077652370ffe9e871
Signed-off-by: Bernhard Rosenkränzer <Bernhard.Rosenkranzer@linaro.org>
...uninstalling updates to a system app
Things seem to be working fine, however we were not as aggressive at
writing out the current state in this case as we probably should be.
Also introduce more features to the appops command, which are useful
for testing this.
Change-Id: I177a9cc0e16e98b76fee0d052d742e06842bb3f9
Don't refer to classes as structs and view versa -- causes warnings in
clang (in code built with -Werror)
Change-Id: I4d7f461bcf6fe4e43a14ad2f28ee0e0ddea95abc
Signed-off-by: Bernhard Rosenkränzer <Bernhard.Rosenkranzer@linaro.org>
C++11 defines a real char16_t, which is not implicitly convertible to
uint16_t (and by extension jchar). Add casts as needed.
Bug: 18300613
Change-Id: I00752002ef2e938bdb57f70947e8fd53ec103293
All but a few lines of this is for issue #16013164, which allowed
apps to do some operations as the media uid by having it call
back to them to open a file. The problem here is with the tempory
identity stuff in the activity manager, allowing us to make the open
call as the original caller... ideally we should figure out a way
to just get rid of all of that, but the solution here is actually
easier (even though it doesn't look it) -- we now hand a token over
to the openFile() call that it can use when doing permission checks
to say "yes I would like the check to be against whoever is responsible
for the open". This allows us to do the uid remapping for only this
one specific set of permission checks, and nothing else.
Also fix issue #17487348: Isolated services can access system services
they shouldn't be able to. Don't send any system service IBinder objects
down for the first initialization of an isolated process.
Change-Id: I3c70e16e0899d7eef0bae458e83958b41ed2b75e
This expands the use of EXTRA_REFERRER to be relevant anywhere,
allowing apps to supply referrer information if they want. However,
if they don't explicitly supply it, then the platform now keeps
track of package names that go with Intents when delivering them
to apps, which it can be returned as the default value.
The new method Activity.getReferrer() is used to retrieve this
referrer information. It knows about EXTRA_REFERRER, it can return
the default package name tracked internally, and it also can return
a new EXTRA_REFERRER_NAME if that exists. The latter is needed
because we can't use EXTRA_REFERRER in some cases since it is a Uri,
and things like #Intent; URI extras can only generate primitive type
extras. We really need to support this syntax for referrers, so we
need to have this additional extra field as an option.
When a referrer is to a native app, we are adopting the android-app
scheme. Since we are doing this, Intent's URI creation and parsing
now supports this scheme, and we improve its syntax to be able to build
intents with custom actions and stuff, instead of being all hung up
on custom schemes.
While doing this, fixed a problem when parsing both intent: and new
android-app: schemes with a selector portion, where we were not
respecting any scheme that was specified.
Change-Id: I06e55221e21a8156c1d6ac755a254fea386917a2
Specifically, --ei (int extras) and --eia (int[] extras) now
use Integer.decode(), which means they accept negative
integers, base-16 integers formatted as #NNN and 0xNNN, and
base-8 integers formatted as 0NNN.
Additionally, --ez (boolean extras) can now be specified as
"true", "false", "t", "f", or an integer (any nonzero
treated as true). The previous behavior, based on
Boolean.valueOf(), would silently assign false if you
managed to get the spelling of "true" wrong.
Change-Id: I058254e907308006d403b5b7866c86bcaa03d8d3
