The following link gives a brief description about package installation process in android.
java,dzone,com/articles/depth-android-package-manager
I'm curious to know how the UID of an app is determined during its installation based on set the permissions present in its manifest file.
Also there is the platform.xml (in /frameworks/base/data/etc directory for 4.0 ICS Source code)file which contains list of permissions with gid associated with them. The description says
The following tags are associating low-level group IDs with permission names. By specifying such a mapping, you are saying that any application process granted the given permission will also be running with the given group ID attached to its process, so it can perform any filesystem (read, write, execute) operations allowed for that group.
In a similar way there is a list of high level permissions assigned to specific uid's as well.
My question is when an app is installed with permissions X,Y, Z how does its access specified is it from the mapping from this platform.xml
Also everytime the app is run does the mapping take place at every instant (that doesn't seem right from the initial design of android where the app permissions cannot be changed unless there is an update). So if that is the case where does it store saying this app should run with such and such access or such and such uid.
I hope I made my question clear, let me know if you need more information. I'm just trying to learn more on how the internals of the Android OS work.
Thanks
Related
My device is rooted but every time I tried to open dsploit apps its showing this massage that " It seems like your rom has LD_library_path bug , I am sorry but this is not compatible with dsploit" . Please any one help me to slove this problem
If device basically runs error free, will say you can run any other apps successfully, then Android's LD_LIBRARY_PATH system variable - what is comparable to PATH system variable in Windows OS - is NOT wrongly set.
In your case it seems to me the app in question doesn't serach for used shared libraries in Android's default LD_LIBRARY_PATH, what may be due to an Android ABI mismatch.
FYI:
LD_LIBRARY_PATH tells the dynamic link loader (ld. so– this little program that starts all your applications) where to search for the dynamic shared libraries an application was linked against. Multiple directories can be listed, separated by a colon ), and this list is then searched before the compiled-in search path(s), and the standard locations (typically /lib, /lib64, /usr/lib, …).
You can query content of LD_LIBRARY_PATH variable
Code:
adb devices
adb shell 'echo "$LD_LIBRARY_PATH"'
I'm trying to enable certain features of my custom app that require "dangerous" permissions. Is it possible to force the permissions instead of asking the user for the permissions? We are selling a prepackaged device and don't want to force the users to have to accept the permissions manually. Anything is in the realm of access; the devices are rooted and using adb, side loaded apps, etc are all acceptable solutions.
root permission is the ultimate permission as far as I know.
kouseralamin said:
root permission is the ultimate permission as far as I know.
Click to expand...
Click to collapse
The device is rooted, but the application is not running as "root".
bennycatalyst said:
I'm trying to enable certain features of my custom app that require "dangerous" permissions. Is it possible to force the permissions instead of asking the user for the permissions? We are selling a prepackaged device and don't want to force the users to have to accept the permissions manually. Anything is in the realm of access; the devices are rooted and using adb, side loaded apps, etc are all acceptable solutions.
Click to expand...
Click to collapse
Typically an app will send a notification to ask for permission to use features on user's phone, which user can Allow or Deny. And that for good reason. . Wondering why you want to bypass this mechanism?
From the user's point of view there are the following high risk ( dangerous ) permissions:
Make phone calls
Send SMS or MMS
Read sensitive logs
Display system-level alerts
Kill background processes
Process outgoing calls
Write secure settings
Authenticate Accounts
Read email attachments
Add system service
Read instant messages (IM)
Full list of permissons here.
An app's permissions must be defined in app's Manifest.xml. Only optional permissions the app has declared can be granted and/or revoked. If Android is rooted then granting and/ or revoking an app's optional permissions is done by PM.
ADB Examples:
Code:
adb devices
adb shell "su -c 'pm grant <packageName> <permissionName >.READ_PROFILE'"
and/or
Code:
adb devices
adb shell "su -c 'pm revoke <packageName> <permissionName >.READ_PROFILE'"
A developer reported that an app downloaded from AppGallery could not be installed.
After checking the message to find out more details about the error, I discovered that the error message was actually "Conflicting provider (Error code: -13)", indicating that ContentProvider of the downloaded app conflicted with that of an existing app. The system also provided a description of the error and recommended a solution.
Generally, if a provider conflict occurs when you install an app, it is probably because an existing app has the same ContentProvider. ContentProvider is one of the four Android elements, although it very rarely used. The ContentProvider feature interacts and shares data between processes, which determines that it must be globally unique. Once an app has registered a ContentProvider on the phone, the app installed later cannot use the same ContentProvider. Otherwise, installation will fail.
As expected, installation failed when we found the same ContentProvider settings in the AndroidManifest.xml file after checking the two conflicting apps.
In this case, you can modify the ContentProvider information and install the app again to resolve the problem.
You may have encountered app installation failures during app development. Lets take a look at some of the most often reported errors on Huawei devices, what they mean and how you as a developer can fix them!
The app package is invalid, incomplete, or incompatible with the operating system (result code: -2).
Cause analysis: An invalid package is uploaded for a third-party app.
Solution: Upload a valid app package.
Insufficient storage space (result code: -4).
Cause analysis: The storage space is insufficient for installing an app.
Solution: Open Optimizer and tap Cleanup to free up some storage space on your phone.
An app with the same package name has already been installed on the device (result code: -5).
Cause analysis: The app cannot be installed as the package name already exists.
Solution: Change the package name to a new one.
Incompatible update (result code: -7).
Cause analysis: The package name of the later version is the same as that of the earlier version currently installed, but their signatures are different.
Solution: Change the signature of the later version to that of the earlier one.
Incompatible app that supports ShareUid (result code: -8).
Cause analysis: The installation failed because the signature of the to-be-installed app that supports ShareUid is different from that of the installed app that supports ShareUid.
Solution: Ensure that the signature is the same as that of the installed app that supports ShareUid.
The shared library is lost (result code: -9).
Cause analysis: The Google Maps library that the app depends on does not exist. As a result, the app installation failed.
Solution: It is recommended that you integrate HMS Core into your app to avoid such dependency issues.
An element name of the to-be-installed app is the same as that of an installed app (result code: -13).
Cause analysis: The ContentProvider defined in the app is the same as that of an installed app.
Perform the following steps to find the conflict:
View logs and check the installation failure callback information.
Run the adb command to obtain all ContentProvider definitions on the device, and find the app that caused the conflict. adb shell dumpsys package providers >d:/temp/provider.txt Solution:Uninstall the conflicting app or resolve the conflict.
The app is incompatible with the CPU of the device (result code: -113 or -16).
Cause analysis: Adaptations for specific CPU versions were not performed when the app was packaged.
Solution: Adapt the app for the CPU version of the device in question.
App verification timed out (result code: -21), and app verification failed (result code: -22).
Cause analysis: When the app was being automatically verified by Google Play, the network connection timed out. Usually, the preceding process is not triggered unless Google Play has been updated by the user or by a downloaded app, which leads to verification timeout.
Solution: On the device, go to Settings > Apps > Google Play Services and tap DISABLE on the App info page, or go to Settings > Apps > Google Play Services Updater and tap Uninstall updates in the upper right corner. Then click FORCE STOP (if available) to deactivate the app if it is still displayed in the app list.
On the device, ensure that Google Play Protect is disabled.
The app package failed to be installed because a later version has been installed (result code: -25).
Cause analysis: Android devices allow for the creation of multiple user accounts. A non-owner account may have downloaded and installed a later version of the app in PrivateSpace for testing purposes. If so, the installation will fail.
Solution: Check whether a later version of the app is installed in PrivateSpace by a non-owner account. If so, uninstall the app and install it again.
Parsing failed (result code: -102).
Cause analysis: An error occurred when generating the package, causing parsing to fail.
Solution: Contact the technical support of the corresponding channel to check logs to locate the download path, download the APK again using a browser, and then install the APK in ADB mode to check whether the error occurs again.
The app package does not contain any certificates (result code: -103).
Cause analysis: The app package is for Early Access targeting specific users and does not contain any certificates.
Solution: Add a certificate to the app package.
Unknown error (result code: -111).
Cause analysis: The device is a TD Tech dual-system policing terminal and is customized to limit app installation.
Solution: Instruct users to contact TD Tech for assistance.
If anyone knows descriptions to miuiop please share, I'm curious what they do.
What App Ops does is allow a user to revoke an individual permission for an app. When the app then starts and tries to make an Android system call to access something that the user has now forbidden then Android will return an error and won’t grant access to that data or functionality.
As you can see there are several numbers starting with 100xx. These are the app IDs (UID = user IDs) the system is dealing with. Every app has a corresponding UID which is needed for file permission rights. Example: If only a certain app (UID 10666) has the permission to open a certain folder, the folder will be restricted to u0_a666 (=user 0, that's you, + app UID 10666)
Usually the first UID slots 10001, 10002, ... are system apps since they get started first upon an initial boot of your device. I assume that MIUIOP belongs to the MIUI optimization, but not sure about that. But you can figure it out with the help of the UIDs:
Apk Analyzer - Apps on Google Play
Detailed reports of the applications on your device. 📱
play.google.com
Selecting an app shows you its UID. Unfortunately it doesn't show you the UID in the app's list directly.
So the uid number could be different across different miui versions… unlike standard appops which are the same regardless of device?
Posting a list of the apps just because:
10008 com.miui.core.internal.editor.services
10017 - com.miui.systemui.overlay.devices.android
10020 - com.android.theme.font.notoserifsource (Noto Serif / Source Sans Pro)
10026 - com.android.internal.systemui.onehanded.gestural (One Handed Mode)
10033 - com.android.overlay.gmstelephony
10036 - com.android.systemui.gesture.line.overlay
10037 - com.miui.systemui.carriers.overlay
The app UIDs are assigned ongoing by your system on first boot (for system apps) or after installation (for user apps). Example: The first app you install on your device gets the UID 10201 then the second one gets 10202 and so on. It doesn't depend on your MIUI version or sth like this.