Some applications declare their privileged permission as 'uses-permission-sdk-23(m)',
not 'uses-permission'. Adding '.*' to current regex expression to cover all the cases.
Test: python development/tools/privapp_permissions/privapp_permissions.py
Change-Id: I1ea8c9361bb53035481418631b34607ffecb238c
Signed-off-by: changho.shin <changho.shin@lge.com>
This was done largely so automation can make use of
privapp-permissions.xml generation.
Privapp_permissions.py no longer requires the build environment
to be setup. Instead, system files can be pulled from a connected
device, and aapt & adb can be set via the commandline. Otherwise,
they will default to the environment's default aapt/adb.
Priv-apps and the permission lists can be queried from the device
using command flags as well, removing the need for an Android
image to be built locally.
Bug: None
Test: Diff between previous privapp_permissions output and the
output for these changes was empty for the following runs:
./old_privapp_permissions.py
vs
./new_privapp_permissions.py [-d && -s SERIAL]
./new_privapp_permissions.py --aapt /path/to/aapt
./old_privapp_permissions.py /path/to.apk
vs
./new_privapp_permissions.py /path/to.apk
./new_privapp_permissions.py device:/path/to/apk
Change-Id: Ifaf35607d38c1d74111fd2f05628c0192fc791cb
This was done largely so automation can make use of
privapp-permissions.xml generation.
Privapp_permissions.py no longer requires the build environment
to be setup. Instead, system files can be pulled from a connected
device, and aapt & adb can be set via the commandline. Otherwise,
they will default to the environment's default aapt/adb.
Priv-apps and the permission lists can be queried from the device
using command flags as well, removing the need for an Android
image to be built locally.
Bug: None
Test: Diff between previous privapp_permissions output and the
output for these changes was empty for the following runs:
./old_privapp_permissions.py
vs
./new_privapp_permissions.py [-d && -s SERIAL]
./new_privapp_permissions.py --aapt /path/to/aapt
./old_privapp_permissions.py /path/to.apk
vs
./new_privapp_permissions.py /path/to.apk
./new_privapp_permissions.py device:/path/to/apk
Change-Id: Ifaf35607d38c1d74111fd2f05628c0192fc791cb
This CL adds support for names in APIs: In Kotlin,
all parameter names are part of the API. In Java,
formal API parameter names can be specified with
@ParameterName("<name>"). Metalava now tracks this,
and in signature files, public parameter names
are included in signatures; in stubs, parameter
names (whether public or not) are always used but
the public name if specified will win.
This CL also adds enforcement of parameters in
signature file comparisons (you cannot remove or
change a parameter in an API), and when running
with --check-compatibility, all API change warnings
are turned into errors.
Some misc other bug fixes and cleanup.
Test: Unit tests included.
Change-Id: I0cfe0741f325812328cd643d51a2b1e9d644cc21
Allows building a single file containing all resources, without breaking
the developer mode, and without having to disable minifying.
Bug: 64831661
Test: yarn run dev; yarn run build
Change-Id: Ifc18a776a3a2fba19be6bbb21713741e5dc27223
At the moment the script looks for the jar iside the out dir.
However, if the our dir is set to a different directory via OUT_DIR_COMMON_BASE
the script does not notice that, and errors out saying a build is
needed.
This commits checks if the OUT_DIR_COMMON_BASE is set, then searches the jar in the proper path.
If OUT_DIR_COMMON_BASE is unset, search in "out" like it did before.
Test: Build with OUT_DIR_COMMON_BASE set and unset and verify idegen works in both cases.
Change-Id: Icfcf41af13139bd81f8589bb900debe5ee616022
These must have been added internal in the same release cycle that we
moved this to bootable/recovery in AOSP. They're there now.
Bug: N/A
Test: N/A
Change-Id: Id79a0e87e7cb6c03d01a0e3816a58838771411f2
See build/soong/README.md for more information
Also moves rmtypedefs to use the guava prebuilt from
prebuilts/misc/common.
Test: m checkbuild
Change-Id: I9298967275ca40f8d50841b204cd40612a8a5f56
Do not require to whitelist permissions that are already explicitly denied
using a new <deny-permission> tag
Bug: 64693550
Test: manual
Change-Id: Ic7a65f0f10bffa98b62d196dd6606ea74e40e911
Some old projects might be removed for some reason, especially
the downstream ones. It should be fine to just skip analysing them
because people have stopped working on them.
Test: run the script against an old release
Change-Id: I563905565c4c502036159fce6a386bba13ba25ea
Some old SHA1 might be invalid when we use this tool.
Ignore these projects and keep going on.
Test: run the script against an old release
Change-Id: I5c89911759de6d122052e841eef0b016fa8b1422
We are using this tools on multiple releases (tags).
Create subfolders using release names, so that results won't be
overwitten.
Test: run the script against multiple releases
Change-Id: I9a94940d630874a5b378431f20a6c1182cf11509
