To find "everything" by UID (or GroupID) on a rooted phone, including running processes, system apps and hardware sensors:

# ID=3011; find / -group $ID -o -user $ID   2>/dev/null

Example 1:

# ID=3011; find / -group $ID -o -user $ID   2>/dev/null
/proc/208
/proc/208/task
/proc/208/task/208
/proc/208/task/208/attr
[...]

# ls -la /proc/208/exe
lrwxrwxrwx 1 root root 0 2017-04-04 22:14 /proc/208/exe -> /system/bin/sensors.qcom

Example 2

# ID=10009; find / -group $ID -o -user $ID   2>/dev/null
/data/misc/profiles/cur/0/com.android.cellbroadcastreceiver
/data/misc/profiles/cur/0/com.android.cellbroadcastreceiver/primary.prof
/data/data/com.android.cellbroadcastreceiver
/data/data/com.android.cellbroadcastreceiver/cache
/data/data/com.android.cellbroadcastreceiver/code_cache
/data/user_de/0/com.android.cellbroadcastreceiver
/data/user_de/0/com.android.cellbroadcastreceiver/cache
/data/user_de/0/com.android.cellbroadcastreceiver/code_cache
/data/user_de/0/com.android.cellbroadcastreceiver/code_cache/com.android.opengl.shaders_cache
/data/user_de/0/com.android.cellbroadcastreceiver/shared_prefs
/data/user_de/0/com.android.cellbroadcastreceiver/shared_prefs/com.android.cellbroadcastreceiver_preferences.xml
/data/user_de/0/com.android.cellbroadcastreceiver/shared_prefs/_has_set_default_values.xml
/data/user_de/0/com.android.cellbroadcastreceiver/databases
/data/user_de/0/com.android.cellbroadcastreceiver/databases/cell_broadcasts.db
/data/user_de/0/com.android.cellbroadcastreceiver/databases/cell_broadcasts.db-journal

I had a similar issue with Android 6.0, Moto G 2nd Gen from 2014. I happened to have upgraded the ES File Explorer application and I noticed it was bloated as hell and sucking up a lot of battery. I removed the application from the system, but the application let a zombie process taking up CPU. The UID was similar to yours 10118, and it listed in the battery statistics as the most hungry resource process.

Then I installed an app named "OS Monitor" and noticed that a .esfm file was actually the only process taking up 60% of CPU. I immediately had known that it had to do with ES File Explorer, but wait... I HAD uninstalled ES File Explorer. Yes. The only thing I didn't do was to RESTART the smartphone. Believe me, I was thinking about crazy things, like going root and beat the crap out of that process, throw the phone against the wall, and even started to believe that my battery reached end of life. To my surprise, I simply restarted the phone and the process was gone.

So before taking any drastic measures, try to figure out which app is giving you a bad time, uninstall it and then restart the phone. Check on OS Monitor the CPU usage list, and you should be fine.

Set up adb in a PC, connect the device to the PC, launch a shell on the PC and enter:

adb shell "dumpsys package | grep -A1 'userId=UID'"

Replace UID with the ID you're looking for, such as 10102.

Example:

bash-4.2# adb shell "dumpsys package | grep -A1 'userId=10102'"
   userId=10102
   pkg=Package{46171ce com.android.chrome}
bash-4.2#

The line containing Package{ would show the package name of the app in between whitespace and }. You can do adb shell dumpsys package PKG_NAME (PKG_NAME → package name of an app) to know more details about that package/app.

If the Android is rooted, from adb shell or a terminal emulator app, you can do:

su
cat /data/system/packages.list | grep UID

In the output, anything before the UID is the package name.

Example:

[email protected]:/ $ su
[email protected]:/ # cat /data/system/packages.list | grep 10102
com.android.chrome 10102 0 /data/data/com.android.chrome default 3002,3003,3001
[email protected]:/ #

Alternatively, if you've Busybox or Toybox installed and available under PATH variable, from a terminal emulator or adb shell do:

su
find /data/data/ -type d -group UID -maxdepth 1 | xargs basename

Example:

[email protected]:/ $ su
[email protected]:/ # find /data/data/ -group 10102 -type d -maxdepth 1 | xargs basename
com.android.chrome
[email protected]:/ #

Since we are interested in the label of the app and not the package name, proceed with the answer from GAThrawn or from Izzy.

Android assigns each application a UID (User ID) at install time; unlike PID (Process ID) which is transient and keeps changing all the time, UID stays constant as long as the application is not reinstalled. The UID should be unique to each application, except when the application explicitly requests to share a userid with another application (there are security restrictions around this, the two applications must be signed with the same private key, i.e. comes from the same developer).

These applications claims to show UID of applications:

• https://market.android.com/details?id=redfishandroid.appexplorer
• https://market.android.com/details?id=com.sayhello2theworld.te

EDIT:

Try looking at /data/system/packages.xml (you need root to view this file), each installed application should have an entry there. Say, I have Adobe Reader installed in my phone:

<package name="com.adobe.reader" codePath="/mnt/asec/com.adobe.reader-1/pkg.apk" flags="262144" ts="1300539048000" version="37149" userId="10034" installer="com.google.android.feedback">
<sigs count="1">
<cert index="21" key="... very long random string ..." />
</sigs>
<perms />
</package>

My phone have assigned userId="10034" to Adobe Reader.

For applications that have requested to share user id with another application, say Handcent:

<package name="com.handcent.nextsms" codePath="/system/app/HandcentSMS.apk" flags="1" ts="1217592000000" version="373" sharedUserId="10064">
<sigs count="1">
<cert index="17" key="... very long random string ..." />
</sigs>
</package>

then the attribute you're looking for is sharedUserId="10064"

In ADB shell (or terminal emulator) use the following command:

cat /proc/<your_process_id_here>/status

and look in the "Name" field. This should be the name of the process. So in your case it would be "cat /proc/10058/status"

Install a terminal emulator, launch it and run:

ps | grep 10058

ps lists the processes and grep filters for the ID you want.

But this only works if the application is running when you run the command.