Status Update
Comments
jj...@google.com <jj...@google.com> #2
For the statement an app that mostly works in background does not mean its unimportant for the user
, actually if it's important to the user, it should try to stay in the foreground, i.e., using a
For the phantom processes, it's really a grey area, where the system does allow this kind of processes, but it's not formally supported, and it's not tracked by the system previously - it's going to hurt the overall system performance, as in resource-limited environment, other processes could be starving because of it. Thus we can't let the number of such kind of processes grow arbitrarily. The 32
may or may not be a good number, at least it's in par with the max cached processes, it's hard to justify what number is the perfect one though. I'd also be un-favor with the idea of introducing the per-package limit - from the system health point of view, it doesn't make sense to me.
For the battery optimizations disabled
, this is orthogonal to the problem here I think. The battery optimization is more about the controls about background activities like Jobs/Alarms which could impact the battery negatively, while the problem here is more about other system resources such as CPU time and RAM.
For the cases like McAfee Security
app, as you also show, the order of the killing is basically based on the parent process's oom adj score - if you app is killed before McAfee, that means it has a better oom adj score.
ag...@gmail.com <ag...@gmail.com> #3
it should try to stay in the foreground, i.e., using a foreground service.
By background, I meant not visible like a social media app, and minimized to notifications. The TermuxService
already 200
, while McAfee app also is a foreground service, but is usually at 100
oom adj, likely because of additional connections, and hence it survives, while Termux does not. Normally the heuristic of giving priority to McAfee would be fine-ish, but the heuristic is still just a guess at what is more important. What the OS's guess is of what's more important is not always what's more important for the user. An OS can't decide such a case. I ask a user, what he would rather have killed?, the Termux app that has important on-going work for him, which has session data that will be lost if its killed and can't be reproduced or like a backup operation going on that will have to restarted from scratch, costing with more CPU + battery + network bandwidth usage later, or would he rather have the McAfee app killed, that can just be restarted later and continue its monitoring again, without permanent data loss, since scans are reproducible. Even if loss was permanent for the later case, it may not be important to the user. I'm pretty sure the answer will be Termux for lot of users, if not most. I don't think one would hear many complaints of "Oh no, my antivirus got restarted and its scan data got lost!". Wouldn't it be better that the user gets to decide what the OS obviously can't decide. Moreover, as an app developer, the only choice would be to create useless connections to try to lower the oom odj to compete with MacAfee app, which would then waste OS resources and even that would be playing russian roulette.
The 32 may or may not be a good number, at least it's in par with the max cached processes, it's hard to justify what number is the perfect one though. I'd also be un-favor with the idea of introducing the per-package limit - from the system health point of view, it doesn't make sense to me.
How about, since 32
may not always be a good number, or will be different for each device or even each user, add a configurable option in android settings, or perhaps developer settings, like it is for cached processes, with a disable completely option as well for power users. Although, this doesn't solve the excessive usage killing issue.
it's going to hurt the overall system performance, as in resource-limited environment
I have a LG G5
, with Snapdragon 820
and 4GB
RAM + 2GB
swap in /data
partition, so its an old device but it runs apps relatively fine even today, with shell processes running through out the day. Some shell processes do take extra CPU and RAM usage, like daily compression+encryption backups, but those last a few minutes, and I as a user, I am completely fine with getting slow downs for a few minutes and don't want OS to kill such processes. I also have longer backups to the cloud, that run for over an hour during the night, with even more CPU usage, and they run without causing any user experience loss since I am not even using the phone and its on charging so battery is not an issue either. With the new design such things are not possible reliably. One would not want to wake up and find out that the OS decided to randomly kill their backup process during the night to save resources. I also use Activity State Changes Tasker Project
logcat
processes and each transition runs dumpsys
command as well to check fullscreen mode. I have never noticed any noticeable lag because of all that, in fact I have to put delays of like 1-2s
because the tasks are much faster than required. The Tasker app barely even shows in battery usages in android settings. Other users on r/tasker have hundreds of event based tasks running all the time without any noticeable performance loss or battery usage.
So the argument that phantom processes will harm user experience is not always true. The r/tasker and r/termux users have actively been using such processes without issue for years. Moreover, every user may not even want an even faster OS/device, but a reliable one that is actually useful for his daily work, instead of just being faster. Devices are fast enough today, with batteries large enough too.
I am also not sure how many android OS devs experiment with such stuff in their daily life, who can provide more usable stats on this, even I don't get much time now. Do you guys have any such stats collected from such devs or done as part of development itself, like how killing normal phantom processes (not rogue) of apps like Termux and Tasker actually noticeably improved user experience and system performance for other apps. Those would be interesting to look at.
Yes, I completely agree that phantom processes can decrease system performance in some cases, specially like the case above with McAfee, but the user should get to decide if he is fine with a certain app causing a performance loss, hence the request for an exemption. Moreover, the current design in fact trimmed rogue logcat
processes from 100+
to 32
, but it also killed the bash
process that wasn't even using much CPU and was useful to the user and the design prevented termux from actually running anything, so from a user perspective, the collateral damage is too high.
The battery optimization is more about the controls about background activities like Jobs/Alarms which could impact the battery negatively, while the problem here is more about other system resources such as CPU time and RAM.
Okay, fair enough. But from a user point of view, more CPU usage would be proportional to battery usage and it would have been easier to use the same permission. But if you want to introduce another permission "Disable resource optimizations", that would be acceptable too. Moreover, the apps that already had battery optimization disabled would automatically also get to use CPU unconditionally and bypass phantom process restriction if same permission was used, so that is probably not something one may want and a separate permission is likely more ideal.
The permission check could be added to ActivityManagerService.checkExcessivePowerUsage()
PhantomProcessList.getOrCreatePhantomProcessIfNeededLocked()
jj...@google.com <jj...@google.com> #4
In terms of the oom adj score McAfee vs. Termux, I guess McAfee has a binding from a higher priority processes, such as the system. As you know, the Android OS doesn't have the intelligence to determine which one is important to the user - it has no idea what this app is for, an user could say the Termux is more important to them, while the other user could say McAfee is more important. It's not scalable for the Android OS to ask user in terms of the importance for every single app. Remember, user perception/interaction is a resource too
.
The number 32 is AOSP definition, OEMs could alter this number if they like, there is no any hard requirement on this. I'd say we could explore the option to add a configuration in the developer options for it. But again, this kind of thing is never formally supported as an Android feature, I'm not sure if this Settings makes sense in this context.
However I'd disagree to associate it with the battery optimization settings, as aforementioned, they're orthogonal problems. Actually for most of the users, they don't have an idea about what the turning off battery optimization
would actually mean to them. Apps without battery restrictions, don't mean they could do whatever they want. All of the Android OS users, should be protected from buggy or malicious apps - we do have seen buggy apps with native executables eating up the system resources. I'd also disagree with the statement Devices are fast enough today, with batteries large enough too
, it's never our goal of stopping making faster device and longer battery life.
ag...@gmail.com <ag...@gmail.com> #5
has a binding from a higher priority processes
Yes, that's what I was referring to, check the ProcessRecord
entries which were posted in linked issue.
McAfee ProcessRecord
$ adb shell "/system/bin/dumpsys activity processes | grep -E -A 50 'ProcessRecord\{.*com.wsandroid.suite'"
*APP* UID 10164 ProcessRecord{24e34c1 3461:com.wsandroid.suite/u0a164}
user #0 uid=10164 gids={3002, 3003, 3001, 50164, 20164, 9997}
mRequiredAbi=arm64-v8a instructionSet=arm64
class=com.wsandroid.suite.MMSApplication
manageSpaceActivityName=com.wavesecure.activities.ManageSpaceActivity
dir=/data/app/~~iWO3mRIXmB_uMRsr0gJvYw==/com.wsandroid.suite-IQCqZvqHzO_TB7Dqs4PPsw==/base.apk publicDir=/data/app/~~iWO3mRIXmB_uMRsr0gJvYw==/com.wsandroid.suite-IQCqZvqHzO_TB7Dqs4PPsw==/base.apk data=/data/user/0/com.wsandroid.suite
packageList={com.wsandroid.suite}
packageDependencies={com.google.android.webview}
compat={440dpi}
thread=android.app.IApplicationThread$Stub$Proxy@2d1b295
pid=3461
lastActivityTime=-1m3s99ms
startSeq=41
mountMode=DEFAULT
lastPssTime=-1m14s752ms pssProcState=4 pssStatType=1 nextPssTime=+58m44s597ms
lastPss=210MB lastSwapPss=41MB lastCachedPss=0.00 lastCachedSwapPss=0.00 lastRss=220MB
trimMemoryLevel=0
procStateMemTracker: best=1 (1=1 Infinityx)
lastRequestedGc=-15h6m1s363ms lastLowMemory=-15h10m20s35ms reportLowMemory=false
reportedInteraction=false fgInteractionTime=-58s379ms
adjSeq=647074 lruSeq=194598
oom adj: max=1001 curRaw=100 setRaw=100 cur=100 set=100
mCurSchedGroup=2 setSchedGroup=2 systemNoUi=false
curProcState=4 mRepProcState=4 setProcState=4 lastStateTime=-2d8h39m55s697ms
curCapability=LCMN setCapability=LCMN
allowStartFgsState=4
hasShownUi=true pendingUiClean=true
cached=false empty=true
notCachedSinceIdle=true initialIdlePss=81684
lastTopTime=-58s378ms
lastInvisibleTime=2021-11-01 20:53:45.546 (-58s385ms)
hasStartedServices=true
mHasForegroundServices=true forcingToImportant=null
Services:
- ServiceRecord{15396e2 u0 com.wsandroid.suite/com.mcafee.monitor.MMSAccessibilityService}
- ServiceRecord{45bf48f u0 com.wsandroid.suite/com.mcafee.messaging.google.GoogleFCMMessageReceiver}
- ServiceRecord{a1e649e u0 com.wsandroid.suite/com.mcafee.sdk.wp.core.siteadvisor.service.SiteAdvisorService}
- ServiceRecord{c0ba211 u0 com.wsandroid.suite/com.mcafee.broadcast.MMSSystemBroadcastListencerService}
mConnections:
- ConnectionRecord{1036c33 u0 CR com.wsandroid.suite/org.chromium.content.app.SandboxedProcessService0:0:@1ff27a2}
- ConnectionRecord{109c957 u0 CR WACT CAPS com.google.android.gms/.chimera.PersistentDirectBootAwareApiService:@305f2d6}
- ConnectionRecord{6cc1bee u0 CR WPRI com.wsandroid.suite/org.chromium.content.app.SandboxedProcessService0:0:@ba02569}
- ConnectionRecord{b9567ee u0 CR IMP com.wsandroid.suite/com.mcafee.messaging.google.GoogleFCMMessageReceiver:@3cf2169}
Published Providers:
- androidx.lifecycle.ProcessLifecycleOwnerInitializer
-> ContentProviderRecord{bf09faa u0 com.wsandroid.suite/androidx.lifecycle.ProcessLifecycleOwnerInitializer}
- com.mcafee.core.provider.KeyValueDataProvider
-> ContentProviderRecord{d95f79b u0 com.wsandroid.suite/com.mcafee.core.provider.KeyValueDataProvider}
- com.mcafee.core.provider.JSONDataContentProvider
-> ContentProviderRecord{72dd738 u0 com.wsandroid.suite/com.mcafee.core.provider.JSONDataContentProvider}
- com.moengage.core.internal.storage.database.MoEProvider
Termux ProcessRecord
$ adb shell "/system/bin/dumpsys activity processes | grep -E -A 50 'ProcessRecord\{.*com.termux'"
*APP* UID 10383 ProcessRecord{f26c83c 18144:com.termux/u0a383}
user #0 uid=10383 gids={3003, 50383, 20383, 9997}
mRequiredAbi=arm64-v8a instructionSet=arm64
class=com.termux.app.TermuxApplication
dir=/data/app/~~gQtDuMCK77ed6DPdCmeWAA==/com.termux-MfgXPeqANrvwr29oJKqfNA==/base.apk publicDir=/data/app/~~gQtDuMCK77ed6DPdCmeWAA==/com.termux-MfgXPeqANrvwr29oJKqfNA==/base.apk data=/data/user/0/com.termux
packageList={com.termux}
compat={440dpi}
thread=android.app.IApplicationThread$Stub$Proxy@f4fbbd
pid=18144
lastActivityTime=-53s621ms
startSeq=4028
mountMode=DEFAULT
lastPssTime=-59s212ms pssProcState=4 pssStatType=1 nextPssTime=+4m4s71ms
lastPss=20MB lastSwapPss=379KB lastCachedPss=0.00 lastCachedSwapPss=0.00 lastRss=57MB
trimMemoryLevel=0
procStateMemTracker: best=1 (1=1 7.59375x)
lastRequestedGc=-9m30s398ms lastLowMemory=-9m30s398ms reportLowMemory=false
reportedInteraction=false fgInteractionTime=-50s903ms
adjSeq=647062 lruSeq=194591
oom adj: max=1001 curRaw=200 setRaw=200 cur=200 set=200
mCurSchedGroup=2 setSchedGroup=2 systemNoUi=false
curProcState=4 mRepProcState=4 setProcState=4 lastStateTime=-9m30s394ms
curCapability=-CMN setCapability=-CMN
allowStartFgsState=4
hasShownUi=true pendingUiClean=true
cached=false empty=true
lastTopTime=-50s903ms
lastInvisibleTime=2021-11-01 20:53:37.304 (-50s903ms)
hasStartedServices=true
mHasForegroundServices=true forcingToImportant=null
Services:
- ServiceRecord{ecab86c u0 com.termux/.app.TermuxService}
mConnections:
- ConnectionRecord{44ab2ca u0 com.termux/.app.TermuxService:@99e35}
Published Providers:
- com.termux.filepicker.TermuxDocumentsProvider
-> ContentProviderRecord{e30f5b2 u0 com.termux/.filepicker.TermuxDocumentsProvider}
- com.termux.app.TermuxOpenReceiver$ContentProvider
-> ContentProviderRecord{f610903 u0 com.termux/.app.TermuxOpenReceiver$ContentProvider}
Connected Providers:
- 8f1e68c/com.android.providers.settings/.SettingsProvider->18144:com.termux/u0a383 s1/1 u0/0 +9m30s337ms
lastCompactTime=0 lastCompactAction=0
isFreezeExempt=false isPendingFreeze=false isFrozen=false
Activities:
- ActivityRecord{aa40b10 u0 com.termux/.app.TermuxActivity t270}
Recent Tasks:
- Task{eb62c28 #270 type=standard A=10383:com.termux U=0 visible=false mode=fullscreen translucent=true sz=1}
BoundClientUids:[10383]
Configuration={1.0 310mcc150mnc [en_US,es_US,nb_NO] ldltr sw392dp w392dp h767dp 440dpi nrml long port night finger -keyb/v/h -nav/h winConfig={ mBounds=Rect(0, 0 - 1080, 2220) mAppBounds=Rect(0, 0 - 1080, 2176) mMaxBounds=Rect(0, 0 - 1080, 2220) mWindowingMode=fullscreen mDisplayWindowingMode=fullscreen mActivityType=undefined mAlwaysOnTop=undefined mRotation=ROTATION_0} as.2 s.6012 fontWeightAdjustment=0}
OverrideConfiguration={1.0 310mcc150mnc [en_US,es_US,nb_NO] ldltr sw392dp w392dp h767dp 440dpi nrml long port night finger -keyb/v/h -nav/h winConfig={ mBounds=Rect(0, 0 - 1080, 2220) mAppBounds=Rect(0, 0 - 1080, 2176) mMaxBounds=Rect(0, 0 - 1080, 2220) mWindowingMode=fullscreen mDisplayWindowingMode=fullscreen mActivityType=standard mAlwaysOnTop=undefined mRotation=ROTATION_0} as.2 s.1 fontWeightAdjustment=0}
mLastReportedConfiguration={1.0 310mcc150mnc [en_US,es_US,nb_NO] ldltr sw392dp w392dp h767dp 440dpi nrml long port night finger -keyb/v/h -nav/h winConfig={ mBounds=Rect(0, 0 - 1080, 2220) mAppBounds=Rect(0, 0 - 1080, 2176) mMaxBounds=Rect(0, 0 - 1080, 2220) mWindowingMode=fullscreen mDisplayWindowingMode=fullscreen mActivityType=undefined mAlwaysOnTop=undefined mRotation=ROTATION_0} as.2 s.6012 fontWeightAdjustment=0}
an user could say the Termux is more important to them, while the other user could say McAfee is more important. I
Yes, exactly. That is exactly the situation a permission would help in. One would grant permission to Termux, the other to McAfee. User decides for android on who to prioritize. If both have permission, then oom adj can be used as fallback. Of course, that situation wouldn't occur in context of phantom processes, since phantom process records wouldn't be tracked if permission was granted.
It's not scalable for the Android OS to ask user in terms of the importance for every single app.
Android does not need to ask. Only a runtime setting needs to exist and apps that are phantom process oriented can ask the user to grant them. Battery optimization permission exists too after all and so does draw over apps and these are already being used by such apps without complaints from users, other than OEM killers of course.
I'd say we could explore the option to add a configuration in the developer options for it.
That would be great and at least would be something. However, a permission exemption would still be better a way in my opinion because if its based on permission, then only specific apps will get to run phantom processes that were explicitly granted to do so and possibly trusted to be reliable. The other apps would still be restricted to the 32
limit and issue of rogue/buggy processes wasting system would be handled as well, which will improve user experience and performance, which is apparently your desired goal. If a configurable limit is used, then it would apply to all apps, and the rogue apps would be allowed to waste resources and users increasing the limit will suffer. But if the permission is not going to be added, then a configuration settings would be greatly appreciated, since at least adb
or root
will not be required, which would be better for users and devs.
Note that com.google.android.gms
overrides the device config received from google servers after BOOT_COMPLETED
event, as mentioned in the Why device config may get reset?
section, so that case would need to be handled too, so that user setting is not overridden. Currently, that is also the issue with setting max_phantom_processes
to 2147483647
, since config gets overridden at boot, and user needs to set max_phantom_processes
after that happens on every boot or has to disable config sync, which is of course not advisable for normal users. Moreover, even max_cached_processes
value set in developer options does not survive reboots, since mOverrideMaxCachedProcesses
gets set to -1
at boot. So asking user to set a value on every boot from developer options is not good from a usability perspective.
But again, this kind of thing is never formally supported as an Android feature
Background processes and daemons are part of linux kernel, like the execvp
10
years that it may be time do so if explicitly allowed by the user. Nothing wrong with opening things up sometimes, instead of locking them up.
Apps without battery restrictions, don't mean they could do whatever they want.
Sure, but killing processes like in case of phantom processes when there is no significant CPU usage or memory pressure is not good either. Killing them under memory pressure based on their oom adj when the time comes is perfectly fine. But before that, if the user wants them to, let them keep running in background and use the CPU as needed.
it's never our goal of stopping making faster device and longer battery life.
Yeah definitely, don't stop improving. I completely agree. I meant in the context that things are fast enough that a user may be satisfied with current levels of performance. If something gets done currently in 100ms
and after optimizations it gets done in 80ms
, he may still be fine with not having that extra boost, if he has to give up customizability and freedom for it. Users are often also not upgrading their devices every year to newer models, since a lot of them are fine with the performance of their device.
jj...@google.com <jj...@google.com> #6
BTW, as a workaround, can you try this command, it effectively bump the limit to 1024
adb shell device_config put activity_manager max_phantom_processes 1024
and use this command to check the result
adb shell device_config get activity_manager max_phantom_processes
jj...@google.com <jj...@google.com> #7
Okay I saw you're aware of the above command already, this at least eliminate the limit 32
here. And for the killings, as if the app has a foreground service, it won't be killed unless under severe memory pressure.
Android runtime permission is designed for privacy concerns specifically, here it's not the case apparently. Battery optimization is NOT a permission.
The argument like 100ms to 80ms doesn't make sense to me, at least there are some scenarios where every millisecond matters. I totally understand your point that, if a user does want to do this, just allow it. All the cases here are specifically for the advanced users IIUC, that's why I was proposing a developer option settings.
ag...@gmail.com <ag...@gmail.com> #8
I am aware of that. It's already listed in the How to disable the phantom processes killing?
section at Integer.MAX_VALUE
(2147483647
)if (mService.mConstants.MAX_PHANTOM_PROCESSES < mPhantomProcesses.size())
condition will always fail in PhantomProcessList.trimPhantomProcessesIfNecessary()
So far, Termux has been working as expected. I have ran a Python script multiple times in the last 24 hours for anywhere between 20 to 90 minutes at a time with no issues so far. Even just now looking through the antivirus app while running Termux hasn't caused it to get killed So far, the setting is still 2147483647
I also asked in first comment if disabling it completely has any harms that I am not seeing, other than "useless" bookeeping going on for processes that will never be killed. The user experience should be consistent with android < 12
in that case, right?
But as mentioned above, that setting is overridden by gms after BOOT_COMPLETED
unless adb shell "/system/bin/device_config set_sync_disabled_for_tests persistent
is run to disable config sync. Denying gms
the WRITE_DEVICE_CONFIG
permission is not a possibility like its gms
overrides.
ag...@gmail.com <ag...@gmail.com> #9
Sorry, saw your comment after I already commented.
if the app has a foreground service, it won't be killed unless under severe memory pressure.
Yes, the service is not getting killed, but the terminal login
shell process gets killed even though its the child of the app
process, so can't really use the app with the login
shell (bash
) dead. Check the picture
Battery optimization is NOT a permission.
Yeah, I understand the context in which you say android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS
is really not a permission and so "Disable resource optimizations" can also not be called a permission ;) Although, that doesn't appear to be on the table, so its fine.
specifically for the advanced users IIUC, that's why I was proposing a developer option settings.
I personally am fine with that as long it survives reboots and is not overridden by gms
config update and there is a completely disable
setting, although 1024
seems high enough. This would be great for power users. Thanks
jj...@google.com <jj...@google.com> #10
Yes it's disabled via the adb command above, it should be behaving the same as earlier Android OS.
BTW, it'll never reach 2147483647
, there is a max process limit typically, you should be able to get it via ulimit -a
I'm not an expert of the gms config sync, so not sure why it's overwritten somehow. If it does happen, I'd reckon that could be a bug somewhere.
jj...@google.com <jj...@google.com> #11
Re #9
If I read the
ag...@gmail.com <ag...@gmail.com> #12
it should be behaving the same as earlier Android OS.
Cool.
BTW, it'll never reach 2147483647, there is a max process limit typically, you should be able to get it via ulimit -a
Ah, I didn't think of the process limit itself. Thanks for pointing that out.
I'm not an expert of the gms config sync, so not sure why it's overwritten somehow. If it does happen, I'd reckon that could be a bug somewhere.
Check the Why device config may get reset?
section or search for updateFromConfigurations
. It details how it happens. Gms just replaces the current settings with the custom one it receives.
On Pixel 5, even max_cached_processes
is set to 64
via update, even though in OS source, default is 32
. Check the What are default cache settings?
section.
At this point I am regretting not posting my comment in a github gist instead, would have been much easier to link sections. Sorry, about that.
ag...@gmail.com <ag...@gmail.com> #13
If I read the github comment correctly, that login process was killed due to trimming, while when the config works, it shouldn't happen IMO?
It gets killed with the default 32
value since the buggy McAfee app is taking all the slots since its actually running 100s of logcat
processes (found when limit was removed). If value is set to 2147483647
, then bash
and other processes are not killed.
while when the config works
Not sure what you mean by config here though.
jj...@google.com <jj...@google.com> #14
Are you saying the max_cached_processes
is being reset, or the max_phantom_processes
is being reset? I'm not surprised by the former one, but the latter one shouldn't happen.
ag...@gmail.com <ag...@gmail.com> #15
The DeviceConfig.setProperties()
gms
which overrides the properties for the namespaces and removes any properties whose keys are not part of the properties objects passed. The gms
decompiled source code is also posted in the gms classes
collapsed section.
All configs in all namespaces, not just activity_manager
are completely overwritten, or at least activity_manager
and media
are. Most namespaces don't have any properties set by default so I tested only 2
. Happens on android 11 too.
# Initial at boot
$ adb shell "/system/bin/device_config list activity_manager"
max_phantom_processes=2147483647
max_phantom_processes1=1
push_messaging_over_quota_behavior=0
# After few minutes
$ adb shell "/system/bin/device_config list activity_manager"
push_messaging_over_quota_behavior=0
ag...@gmail.com <ag...@gmail.com> #16
Are you saying the max_cached_processes is being reset, or the max_phantom_processes is being reset?
Both are removed on emulator.
On pixel 3a after restart in which max_phantom_processes=2147483647
was already set before reboot, following is returned. Note max_cached_processes=64
value.
$ adb shell "/system/bin/device_config list activity_manager"
compact_full_delta_rss_throttle_kb=8000
compact_full_rss_throttle_kb=12000
compact_proc_state_throttle=11
compact_statsd_sample_rate=0.0
max_cached_processes=64
oom_re_ranking_lru_weight=0.35
oom_re_ranking_number_to_re_rank=8
oom_re_ranking_rss_weight=0.15
oom_re_ranking_uses_weight=0.5
push_messaging_over_quota_behavior=0
use_compaction=true
use_oom_re_ranking=false
ag...@gmail.com <ag...@gmail.com> #17
And considering that it doesn't look like the permission exemption will be added for apps, it would be great if developer options adds an additional toggle for "do not kill processes using extension cpu". It would allow apps like termux and tasker to run processes that use CPU for more than a few minutes, like even common linux commands like zip
, xz
, gpg
, rsync
, rclone
which are CPU extensive by nature. Such commands are common among our users and other power users. Such processes would still get killed under memory pressure but that's understandable.
If a permission were to be added, then only specific apps could have been allowed to use extensive cpu, but since its not, a global toogle would be great so that power users can get old android experience.
ag...@gmail.com <ag...@gmail.com> #18
Also note that some apps like bank apps refuse to run if a user has enabled developer options, and don't consider such users/developers "normal human beings", so that will be a concern too. Custom settings like max_cached_processes
are reset to default if developer options are disabled, so "power users" won't be able to run such apps including bank apps if settings are added to developer options, instead of a permission.
ag...@gmail.com <ag...@gmail.com> #19
Additional excessive CPU usage use cases
So I completely forgot some other important use cases that needs excessive CPU and memory. Termux supports on-device code compilation from source code, including xfce4
, etc for on our own
The termux app provides 1000+
packages from our main reposcience
, game
, root
, x11
)cpan
, gem
, npm
or pip
), do not take too much disk space, do not serve duplicated functionality and not hacking related. Moreover, we only keep the latest version of each package on our servers so that older version don't use storage.
So all the packages/code that fall out of these conditions are compiled locally by users. This may include
Users also compile other open source codes available on the internet or their own code written for the
Termux recently also started providing openjdk-17
, kotlin
and gradle
and users can now also
The maintainers and contributors often compile code locally on their device, specially the ones that don't have PCs, before they send
Someone may reply and say that android does not support executing compiled code from app private data directory for targetSdkVersion
> 28
due to W^X violation
targetSdkVersion
28
. But that discussion would be off-topic for this issue.
Some people may also claim that the phantom process trimming and excessive CPU restrictions will only effect a relatively few people, so who cares. So let me provide some stats. Tasker alone (not other automation apps) have 1M+
downloads on playstore10M+
downloads on playstore
Our primary packages server was being donated 64TB
month bandwidth by Bintray30
Oct, we changed our primary server in pkg
script from Fosshost to pkg
script (termux-tools
) version till now may be using it instead of Fosshost one and other mirrors based on weighting. Since cloudflare does keep stats (check attachments), it shows a spike in its usage and is currently at 30K
unique visitors/day and 733K
requests/day. For last 30
days, it had 526K
unique visitors and 21M
total requests, even though it wasn't even in the pkg
script and would have to be manually set by users as the repo in sources.list
, like via termux-change-repo
To provide another data point/angle from grimler's mirror, the libllvm
(compiler) has been the top 10
of most downloaded packages every day for the last 14
days, with 2645
average downloads per day with 47100
average unique visitors per day. Based on its 17
15500
libllvm
downloads per day and 280K
unique visitors in total on all 5
repos in pkg
script, not including chinese, which is a whole other world. Of course, these estimates may not be accurate.
So that is a whole lot of users who are compiling code, who would be affected by excessive CPU restrictions, not just a few. Compilations can take from a few minutes to many hours. And such users have been compiling code for years on android without complaints. And now that compilation has become even faster due to faster CPU/memory and larger memory, putting restrictions in place without exemptions is actually counterproductive for such users. Why improve performance if you can't actually use it? Slow downs during such compilation are expected by the user. When a developer compiles code on PC, like android source or apps, he pretty much expects that PC may slow down to a halt and he may barely be able to use it, with windows hanging and all, but that doesn't mean that OS should just kill the compilation process to free resources. That's not what the user wants!
So exemption for both trimming and excessive CPU usage must be provided and are equally important.
Some people have also responded to me (which I'm relaying) that a "developer" != "power user" and are not it support of a developer option and prefer a permission. Android may be partially treating them the same over the years, and it may probably be too late in the game to change it now, but putting such an option in developer option will have issues like apps checking if developer options is enabled and OEMs not providing the option in their fork or not allowing config to be changed even over adb
. So such things need to be considered.
Phantom Processes List
I also had another thought. If the goal of android is to actually improve performance by tracking rogue processes that may be wasting resources, I think it would be beneficial if the currently tracked phantom processes, recently trimmed processes, and excessive CPU usage processes are shown in the processes list in developer options. The list should probably include info of uid
, pid
, process and app oom adj, and full commandline. The commandline should probably be trimmed, cause it may take lot of memory and cause crashes (activity limits), cause it can be 128KB
or more, defined by ARG_MAX
. Maybe copy list support too since lot of records may exist if limit is increased.
Firstly, from a developer perspective, considering not everybody knows command line and don't know how to use adb
and ps
, etc to find which processes their apps are running, it would be beneficial to see them in the GUI and know if they are being killed. Even developers who know command line probably don't check such processes. So this should help developers debug problems in their code, instead of android just silently killing them without anyone knowing, and bug continuing on an on.
Secondly, from a user perspective, it would be more clear to a user what processes such apps are running in the background and how android is managing them. It could also help users report bugs to devs more easily too, like the case of McAfee or for user or device specific issues.
Move of phantom processes info
I have also moved the detailed comment at
pj...@gmail.com <pj...@gmail.com> #20
ch...@cambrian.edu.bd <ch...@cambrian.edu.bd> #21
I just want to say I agree that there should be a way for power users to grant freedom to certain apps to bypass this limitation. it's good to trim the fat but you should recognize that there are a lot of users whose setups would be crippled by this, you can/should allow us to bypass the limit for the apps we want to keep using.
I totally agree with this.
sk...@gmail.com <sk...@gmail.com> #22
Also as another aside, the fact that this wasn't even communicated in 12's changes means this is taking everyone completely by surprise. It means that every app developer that starts getting flooded with bug reports will spend inordinate amounts of time on wild goose hunts because you decided hard killing random processes was somehow better for everyone, and didn't consider that the entire world might want a heads up. For a change of this much consequence, the fact that this is only known because someone hunted it down in the source code history is not ok.
I know as core devs, your perspective is often in the extremes of preventing malicious apps, poorly written apps, and working within very resource constrained environments. I get it. But you can't lose sight that these are not anything close to the average experience that most people have.
Whatever problem you were trying to solve, this was a brobdingnagian hammer.
jj...@google.com <jj...@google.com> #23
Re #22,
As mentioned above, this is never formally supported as an Android feature, I don't think there is a need to mention changes for something we've never formally supported.
ag...@gmail.com <ag...@gmail.com> #24
The RunTime
class was added in the 7
exec
tested (check References
of RunTime
class, like OldRuntimeTest
exec
call is not marked as UnsupportedAppUsage
loadLibrary
call which was
Android AOSP /system/bin
/system/vendor/bin
by individual vendors, which have been updated in each android version over the years, including Android 12
, mainly via grep
. Android also provides lot of android specific binaries including logcat
, am
, pm
, cmd
, settings
, etc and even has special permissions like READ_LOGS
and WRITE_SECURE_SETTINGS
, etc as official development permissions. Android google-api's avd even ships with su
binary. How are all these "features" unsupported or supposed to be called without forking processes?
The ulimit
(max user processes) is being shown as 14348
on my Android 7
and 6653
on Android 12
, so android is not even limiting that either. Android is based on linux kernel so one can't really say child processes have been unsupported by Android considering its core part of the linux kernel.
Child processes being discouraged by android devs in forums since it can waste resources by bugs and poor implementation is not really an official stance or good enough reason to block/limit forking for all apps without allowing exemptions to be granted by the user. It only takes one process to waste resources in badly written apps and I am sure we have all seen such apps.
jj...@google.com <jj...@google.com> #25
The Runtime.exec
is still working as of today, even Android 12
. This API is more a legacy thing from the initial Java API, which was to allow some native utilities to run in early days, but many of them were being replaced with Android implementations later. These native child processes are something not managed by the Android system, from the life-cycle to resource management to security models. Android developers are discouraged from using these as you also mentioned. I don't know if there is a plan to deprecate it, but I wish so. The
The bug here is more about to the number of maximum child processes forked from this. There was no such a document about how many child processes the Android is allowing at all. The ulimit
number in Android 7
and Android 12
is mentioned nowhere, OEMs are free to make changes on their own, the termux
happens to working well before because nobody limited it before. All these other utilities like am
, pm
are supposed to be used from adb shell, otherwise many of their functions would be broken because it's not running with the correct user credentials.
As mentioned above, I'm adding a developer options to allow turn the monitoring mechanism off. Stay tuned.
ag...@gmail.com <ag...@gmail.com> #26
security models.
SeLinux policies and android permission models do apply to such processes. pm
etc ran via cmd
but I wish so?
Isn't the system implemented now to monitor such processes and kill excessive ones good enough (apart for 32
), why do you wish for such things to be completely disabled, considering millions of users around the world have different use cases for them and have been using them for years, even if you don't? Note that I'm in full support of monitoring, killing and increased security, as long as exemptions can be allowed by user.
As mentioned above, I'm adding a developer options to allow turn the monitoring mechanism off. Stay tuned.
Thanks! That's some great news!
Will options be provided for both max phantom processes and excessive CPU usage? A device config option could be added to disable excessive CPU monitoring considering a permission is not being added.
Will those settings be reset if developer options are disabled after custom values are set, considering issues with bank apps and gaming apps checking if developer options are enabled. If yes, then maybe two settings should be created for each. One in activity manager settings and one in device config, like mOverrideMaxCachedProcesses
is in activity manager settings and set via BackgroundProcessLimitPreferenceController
max_cached_processes
does not. Such users who don't want or can't enable developer settings could set device config variants over adb instead.
How will gms config update issues be handled? u/DutchOfBurdock has notified me that config update was sent after 3-4 days after reboot and custom max_phantom_processes
value was reset. When value is updated, updateMaxPhantomProcesses()
trimPhantomProcessesIfNecessary()
, which would result in any processes greater than 32
to get killed. So processes would randomly be killed whenever gms
decides to send an update or update the values. For such cases,
ag...@gmail.com <ag...@gmail.com> #27
Thanks a lot Jing Ji for
Based on the commit, trimming of phantom processes and excessive CPU usage of phantom processes will not be done if flag is off, but later will still be done for main app process. Monitoring of excessive CPU usage of main app process should not be an issue for Termux since it itself doesn't use excessive CPU, like for compilation, etc and its consistent with old android version behaviour.
The flag should also not reset to default when dev options are disabled, which is great since it solves the mentioned issue of bank/games apps checking if dev options was enabled. I confirmed by testing current flags in android 12 and they are not reset.
Will this likely be merged for Android 12L or any expected timeline? Even if its merged for android 12L, it would still be a concern for devices that are shipped with android 12 who won't be getting an update anytime soon or possibly at all for 12L. Or which were released with old versions and will max receive android 12, or earlier revisions.
And Thank You again for listening to the concerns of the community!
jj...@google.com <jj...@google.com> #28
Thanks for reporting this. I've merged the CL, it should be able to make into Android 12L.
ag...@gmail.com <ag...@gmail.com> #29
You are welcome. That's great. Thanks again.
jd...@gmail.com <jd...@gmail.com> #30
jj...@google.com <jj...@google.com> #31
Re #30. Sorry I don't have this information, you'd probably need to check with the individual OEMs.
ga...@gmail.com <ga...@gmail.com> #32
ga...@gmail.com <ga...@gmail.com> #33
mi...@gmail.com <mi...@gmail.com> #34
Hoping this feature is offered everywhere soon. Thanks.
mi...@gmail.com <mi...@gmail.com> #35
jj...@google.com <jj...@google.com> #36
Re #35, the CL mentioned in #27 missed the cutoff window of the recent Android 12L beta release build, it should be included in the next beta release though. So stay tuned with the
To the #34, Android 12L is actually a new Android release, it's just smaller in comparison to other releases. IMO, OEMs would have two options: a) cherry-pick this specific CL to their Android 12 maintenance release build, if there is any; b) upgrade it to Android 12L.
ga...@gmail.com <ga...@gmail.com> #37
Sent from Nine
________________________________
From: buganizer-system@google.com
Sent: Monday, January 17, 2022 8:06 PM
To: b-system+-425673847@google.com
Cc: gabrielstangl65@gmail.com
Subject: Re:
Replying to this email means your email address will be shared with the team that works on this product.
Changed
jj...@google.com added
Re #35, the CL mentioned in #27 missed the cutoff window of the recent Android 12L beta release build, it should be included in the next beta release though. So stay tuned with the
To the #34, Android 12L is actually a new Android release, it's just smaller in comparison to other releases. IMO, OEMs would have two options: a) cherry-pick this specific CL to their Android 12 maintenance release build, if there is any; b) upgrade it to Android 12L.
_______________________________
Reference Info: 205156966 Phantom Process Killing In Android 12 Is Breaking Apps
component: Android Public Tracker
status: Assigned
reporter: ag...@gmail.com
assignee: jj...@google.com
cc: ag...@gmail.com, jj...@google.com
type: Bug
priority: P3
severity: S3
retention: Component default
Generated by Google IssueTracker notification system
You're receiving this email because you are subscribed to updates on Google IssueTracker
Unsubscribe from this issue.
ga...@gmail.com <ga...@gmail.com> #38
mi...@gmail.com <mi...@gmail.com> #39
I'm curious what the motivation was here though. Why was it decided for me that I want to max out at a very low 32 child processes? This is very unlike Android in my opinion and caught me off guard.
na...@gmail.com <na...@gmail.com> #40
This 'feature' albeit possibly necessary is very annoying...
v8...@gmail.com <v8...@gmail.com> #41
I pay for new battery!
It is criminal act to restrict me from using software on my phone!
And they are doing that behind my back, so I would't know what is happening.
It is worse than virus, and is crime.!
It is criminal act against phone owners, and it is against the law!
People and myself are loosing money because this virus Phantom Process Killing!
It is virus, planted to cripple millions of phones and render them uselles.
A phones which costs 1000+ Euro!
It is virus and should be treated as virus, and people who did this prosecuted!!!
pa...@gmail.com <pa...@gmail.com> #42
v8...@gmail.com <v8...@gmail.com> #43
V8karlo, get sober!
Now this is answer to that mail:
I paid 1057 Eur for phone and software which I used till yesterday when I updated to A12 does not work anymore.
I bought this phone because that software, and now can throw my phone in trash can!
You get sober!
Promises that it will be corrected are just promises.
And what I am supposed to do until next update?
Loose more money? For months until update?
And what if update was only false promise?
Would you refund all the money my company lost in meantime?
Would you refund me thousands of Euro lost for good?
You better get sober yourself!
v8...@gmail.com <v8...@gmail.com> #44
updated to A12 does not work anymore.
I bought this phone because that software, and now can throw my phone in
trash can!
You get sober!
Promises that it will be corrected are just promises.
And what I am supposed to do until next update?
Loose more money? For months until update?
And what if update was only false promise?
Would you refund all the money my company lost in meantime?
Would you refund me thousands of Euro lost for good?
You better get sober yourself!
On Thu, Jan 27, 2022, 11:52 <buganizer-system@google.com> wrote:
pa...@gmail.com <pa...@gmail.com> #45
v8...@gmail.com <v8...@gmail.com> #46
phantom update.
Every single day!
I don't care who's fault that is, nor my employees.
My employees want paycheck at the end of month,
And I can't make money till the update!
Phantom Process Killing is a virus Plante to kill myself and developers
like me!
On Thu, Jan 27, 2022, 12:08 <buganizer-system@google.com> wrote:
v8...@gmail.com <v8...@gmail.com> #47
Every single day!
I don't care who's fault that is, nor my employees.
My employees want paycheck at the end of month,
And I can't make money till the update!
Phantom Process Killing is a virus Planted to kill myself and developers like me!
v8...@gmail.com <v8...@gmail.com> #48
v8...@gmail.com <v8...@gmail.com> #49
Millions!
You calculate how much money is lost!
And I can not sell product which is constantly killed by virus!
Phantom Process Killing Virus!
Have a nice few months until promised update!!!
I know I WILL Not. I will have nightmares, starting from yesterday when I realized why my product does not function, and it does not function anymore because of that virus!
v8...@gmail.com <v8...@gmail.com> #50
The person who made Phantom Process Killing possible,
Should be in jail, prosecuted for all the damage done,
And I am not talking about few thousand Euro's,
But much, much more. In millions.
Lots of people still does not know why their phones act weirdly,
But they will in time, like I was struck by lightning yesterday!
v8...@gmail.com <v8...@gmail.com> #51
My worst nightmare is yet to come!
Refund the money for the app I sold,
Which is crashing and I can't make it work anymore.
Every user who has my app and update to A12 is
One more for refund!
And you tell me to get sober!
And you who made that virus possible,
I have a need to met you in person, you know what I mean!
To cut your hands, so you can never again touch keyboard!
ag...@gmail.com <ag...@gmail.com> #52
As already commented How to disable the phantom processes killing?
adb
once to prevent phantom processing trimming on Android 12 (at your own risk).
adb shell "/system/bin/device_config set_sync_disabled_for_tests persistent; /system/bin/device_config put activity_manager max_phantom_processes 2147483647"
Disabling device config sync is necessary since gms may reset settings randomly even after boot when update comes. I need to update the gist.
Even with the workaround to prevent trimming, processes using excessive cpu will be killed. So users will have to limit max cpu usage for commands, like compilation commands. Those issues should be solvable for people on android 12L or 13 by disabling the settings_enable_monitor_phantom_procs
feature flag in developer options, assuming above mentioned commit is merged in aosp release and vendor forks and flag is available. Users with root on android 12 should also be able to disable it with xposed/riru modules.
And users (or trolls) should stop spamming this thread and giving threats, screaming here won't help, fix can't be released by google and all vendors instantaneously, updates take time, that's just how android works, other bug and issue fixes exist too that will need to wait. What's done is done, be thankful that an option will be provided in future. Contact your individual vendors, likely on their support thread and ask them to prioritize merging, like already done for samsung.
However, I do agree that, were it not a silent change, it could have been caught earlier and option available in android 12 release. So any future changes to phantom processes should be public, considering the amount of users and apps around the world that rely on them.
mi...@gmail.com <mi...@gmail.com> #53
I understand that these aren't formally supported features but I'm interested in if you believe TARE will have a negative impact on background services that are meant to behave this way.
Thank you again for addressing RE: Android 12L's developer option.
ag...@gmail.com <ag...@gmail.com> #54
The settings_enable_monitor_phantom_procs
flag is available in Pixel Android 12L beta 3 releases (which have been adb shell settings put global settings_enable_monitor_phantom_procs false
over adb or run setprop persist.sys.fflag.override.settings_enable_monitor_phantom_procs false
with root to disable phantom process trimming and killing of processes using excessive cpu. This is not really user friendly, but it is what it is.
mi...@gmail.com <mi...@gmail.com> #55
Appreciate your comment and links.
na...@gmail.com <na...@gmail.com> #56
Said devices are in fact thousands of dollars worth each and had been doing *VERY* well before i decided to update...
Deciding to push this feature in was probably intended for the better but has proven a real nightmare for those of us who do not own computers or have completely switched our methods to be more 'future-forward'
At the very least, this setting should be made directly available from with the Developers Settings options menu, and not under the feature flags, hidden behind a specific build signature that NO USER WHO WANTS TO KEEP THEIR DEVICE IN STOCK CONDITION will ever have access to...
ag...@gmail.com <ag...@gmail.com> #57
na...@gmail.com <na...@gmail.com> #58
"As mentioned above, I'm adding a developer options to allow turn the monitoring mechanism off. Stay tuned."
...we were expecting, from your last sentence, and actual Dev. Option! Not a hidden feature flag.
mi...@gmail.com <mi...@gmail.com> #59
I share these sentiments. Is there any chance that this can be added as an actual developer option in time for Android 12L's final build? Seems as though we are simply trading one ADB command for another.
ag...@gmail.com <ag...@gmail.com> #60
The flag still has value because its safer to use than RescueParty
). Moreover, the flag also disables excessive cpu usage killing so those kinda commands (compilation, GUI, syncs) won't be killed either. But yeah, I agree, developer option should have been available for user builds. Running commands over adb won't be easy for all users, specially non-termux users.
na...@gmail.com <na...@gmail.com> #61
this issue incurs that the android platform tools available I the termux repos should be fixed or patched to enable anyone facing this issue to easily bypass it until it is fully sorted out
ag...@gmail.com <ag...@gmail.com> #62
Another issue is that how would a user even know that a feature flag is supported if feature flags list is not even shown in production devices? getprop
won't show props with default values, and settings global
key would be unset too by default.
The FeatureFlagUtils.getAllFeatureFlags()
dumpsys
and so apparently there is not shell API either to get the supported flags.
Vendors not supporting is definitely a concern since they would not have any obligation to support a feature flag, specially considering their history of aggressiveness against background processes. Hopefully, it will be available in all 12L and 13, but how would a user know it? Usually, normal settings have some UI showing their state, but this one won't. Since there is no API either as far as I can see, users would actually have to try to trigger the phantom process killer by starting > 32
processes and see if the settings
command actually had an affect or not. Not all apps have a terminal or shell APIs either to test this.
However, I have added support in termux app with 68cdbd6f
DEFAULT_FLAGS
and the feature values with reflection from FeatureFlagUtils
and show the value for settings_enable_monitor_phantom_procs
in termux settings about page, but that actually requires bypassing
Considering all this is not really user friendly, Jing Ji can the flag toggle be shown outside feature flags page or even in it for user builds? It would require some additional code but it would really improve user experience. Thanks
ga...@gmail.com <ga...@gmail.com> #63
Sent from Nine
________________________________
From: buganizer-system@google.com
Sent: Saturday, February 12, 2022 9:48 PM
To: b-system+-425673847@google.com
Cc: gabrielstangl65@gmail.com
Subject: Re:
Replying to this email means your email address will be shared with the team that works on this product.
Changed
ag...@gmail.com added
Another issue is that how would a user even know that a feature flag is supported if feature flags list is not even shown in production devices? getprop won't show props with default values, and settings global key would be unset too by default.
The FeatureFlagUtils.getAllFeatureFlags() is not being called anywhere else other than dev options and tests, so at least there is no loop for something dumpsys and so apparently there is not shell API either to get the supported flags.
Vendors not supporting is definitely a concern since they would not have any obligation to support a feature flag, specially considering their history of aggressiveness against background processes. Hopefully, it will be available in all 12L and 13, but how would a user know it? Usually, normal settings have some UI showing their state, but this one won't. Since there is no API either as far as I can see, users would actually have to try to trigger the phantom process killer by starting > 32 processes and see if the settings command actually had an affect or not. Not all apps have a terminal or shell APIs either to test this.
However, I have added support in termux app with 68cdbd6f to get the DEFAULT_FLAGS and the feature values with reflection from FeatureFlagUtils and show the value for settings_enable_monitor_phantom_procs in termux settings about page, but that actually requires bypassing android hidden API restrictions, which is not something normal apps can be recommended to do.
Considering all this is not really user friendly, Jing Ji can the flag toggle be shown outside feature flags page or even in it for user builds? It would require some additional code but it would really improve user experience. Thanks
_______________________________
Reference Info: 205156966 Phantom Process Killing In Android 12 Is Breaking Apps
component: Android Public Tracker
status: Assigned
reporter: ag...@gmail.com
assignee: jj...@google.com
cc: ag...@gmail.com, jj...@google.com
type: Bug
priority: P3
severity: S3
retention: Component default
Generated by Google IssueTracker notification system
You're receiving this email because you are subscribed to updates on Google IssueTracker
Unsubscribe from this issue.
lo...@gmail.com <lo...@gmail.com> #64
#Initial Commit!!!
mi...@gmail.com <mi...@gmail.com> #65
I guess once 12L is deployed to the masses we'll have to open another nearly identical issue 😞
na...@gmail.com <na...@gmail.com> #66
mi...@gmail.com <mi...@gmail.com> #67
mz...@gmail.com <mz...@gmail.com> #68
re...@gmail.com <re...@gmail.com> #69
It depends on your OEM. They have to actually provide the option. If you have a Samsung, you'll need to do it through ADB.
v8...@gmail.com <v8...@gmail.com> #70
Still no option available for Phantom Process Killing on / off switch.
Something went wrong?
mi...@gmail.com <mi...@gmail.com> #71
Also there will be no visible developer option. You will need to execute ADB commands to set an invisible feature flag and then test the device to see if your OEM has opted to allow it.
[Deleted User] <[Deleted User]> #72
ga...@gmail.com <ga...@gmail.com> #73
di...@gmail.com <di...@gmail.com> #74
This may be related -- it appears killing the web view process brings down the entire app, even when a foreground service is active with a notification, even when recording from the mic. This is breaking the Android API.
getHistoricalProcessExitReasons only returns a record for the web view.
ApplicationExitInfo(timestamp=2022-04-06, 9:08 a.m. pid=20757 realUid=99039 packageUid=10283 definingUid=10283 user=0 process=com.google.android.webview:sandboxed_process0:org.chromium.content.app.SandboxedProcessService0:0 reason=13 (OTHER KILLS BY SYSTEM) subreason=17 (ISOLATED NOT NEEDED) status=0 importance=300 pss=28MB rss=105MB description=isolated not needed state=empty trace=null
However, the entire app was terminated.
Example device that is doing this:
Board: msmnile
Brand: samsung
CPU ABI: [arm64-v8a, armeabi-v7a, armeabi]
Device: beyond1q
Manufacturer: samsung
Model: SM-G973W
Product: beyond1qltecs
Version codename: REL
Version incremental: G973WVLS6HVA1
Version release: 12
Version code: 31
ha...@gmail.com <ha...@gmail.com> #75
#74
That's a different issue of webview package becoming a dependency of the app package till app process death if the app opens a WebView
even once. Check 12L
with ec8cff62
WebView
.
di...@gmail.com <di...@gmail.com> #76
#75 Thanks!
di...@gmail.com <di...@gmail.com> #77
Hmm it seems it doesn't totally fix the issue. It will still kill and restart the services if I'm understanding that commit correctly. Unfortunately this would still break things like a foreground service recording from the mic. Hmm, it looks like battery saving mode also wouldn't affect this?
ag...@gmail.com <ag...@gmail.com> #78
Webview package becoming a dependency would be your issue and yes, for your use case, the fix wouldn't work since recording will stop, only services will get restarted. Not using WebView is the only way probably. Disabling battery optimizations shouldn't affect it since its a dependency issue. Maybe jj can recommend something else.
v8...@gmail.com <v8...@gmail.com> #79
It is virus planted behind users back.
Not documented, hidden. ! Targeting third party !
You will not alowed to switch it off.
If they allow to switch it off, they will make it so hard that casual user won't do it .
Think ! Follow the money ! There is no money in Linux or similar.
They hijacked your phone !
Your phone is not yours !
v8...@gmail.com <v8...@gmail.com> #80
And everyone like sheeps, are doing nothing to prevent criminal act !
Enjoy in your, their 1000+ EUR phone !
v8...@gmail.com <v8...@gmail.com> #81
You will pay thousands of EURos for the worthless brick !
ga...@gmail.com <ga...@gmail.com> #82
an...@gmail.com <an...@gmail.com> #83
v8...@gmail.com <v8...@gmail.com> #84
It is been a long time passed from promise about option for switch off Phantom Process Killing .
Any news on progress ??
What happened ?
mi...@gmail.com <mi...@gmail.com> #85
I understand Google is pledging to get more aggressive going forward in regards to killing background processes. Please take this thread into consideration when doing so
v8...@gmail.com <v8...@gmail.com> #86
v8...@gmail.com <v8...@gmail.com> #87
Bye , bye .
I will put my 1000+ Eur in some other type of phone without this crap .
v8...@gmail.com <v8...@gmail.com> #88
They just lost 1 more customer .
jo...@gmail.com <jo...@gmail.com> #89
Android shouldnt be crippled.
I read before that software development in Android is not supported..
Well it is time it should.
i do some development on my phone, i use Samsung Dex and today's phones are perfectly capable of doing development and using as a desktop OS. It could perfectly replace my desktop PC if not for google self imposed limitations on the system.
This phantom killing process has been a big issue for me and i am not even an advanced developer, just a power user with some development more on the business user , not proffesional software development.
Things like this and many of the OEM process killing are actually achieving the opposite of intended behaviour for power users.
Slightly off topic , but as an example of how being over aggressive on optimization by process killing is counterproductive.
I even have problems using web apps like google sheets and app scripts due to crazy and un needed process killing , browser tabs just get killed and need to be re loaded even if sent to the background just seconds. This actually makes working slower, since i need to reload very often, and losing data due to web forms being lost, unsaved edits in app scripts getting lost, etc.
I know the phone can handle it, in fact i can work in the very same phone with a linux distro running in termux, and chromium running in that linux (before this phantom killing update was a thing) and actually work quicker there as i can switch tabs and apps without fear of losing work due to app or browser tab being killed.
Again it is about time general desktop and software development is supported in Android. come on, apple is already using their arm m1 chips on laptops and beating every one else. Mobile chips are more than ready for desktop and power use.
if google doesn't understand this soon , apple or some one else will sooner or later and power users will move there.
v8...@gmail.com <v8...@gmail.com> #90
Definitely , M1 is option for me .
And is true what you say .
I disabled Phantom killing and still web pages losse their contens which make me mad , I lost operation which performs on that tab ,
like converting and downloading video .
That means that there are more proccesses than Phantom killing involved .
Google is destroying me and not helping and thats very bad .
It should allow mw to work , not destroying me !
I can not work because of that .
They are gone to far !
da...@gmail.com <da...@gmail.com> #91
mi...@gmail.com <mi...@gmail.com> #92
na...@gmail.com <na...@gmail.com> #93
na...@gmail.com <na...@gmail.com> #94
I for one am not the only one who now had to purchase a computer over the Samsung hardware I had purchased to move my workflow o er to android entirely, and am back to square one because of how stupidly the Google engineers have handled this.
Reading through the comments, I can see that many are frustrated with Google blatantly doing whatever the hell the want with user's devi es y pushing whatever kind of update they deem 'reliable and secure', at the cost of our wallets and professional reliance.
This ticket is very much the proof of how things are panning out to be in both the near and far future for those of us who chose Android as the better alternative for our daily mobile driver.
Google gave us false hope in making us think we could finally bridge the gap in between normal computing and the mobile alternative, and here we are now struggling to convince them to let us have just a tiny little option toggle, in a very visible and accessible menu, to give us the choice to disable a feature that literally breaks almost everything we try to do that is outside the scope that is intended by Google's vision of Android OS starting version 12. Welcome to Apple 2.0...
Hope you are very happy Google...
v8...@gmail.com <v8...@gmail.com> #95
50% of apps on Play Store lost its full functionality after Android 12 .
Read the comments on each app in Play Store .
Apps becomed uselless , apps which till yesterday worked !!!
Lots of people lost money and time on that apps .
You can not find functioanal controller for games on Android 12 .
I bought expensive PS5 , failed only on Android 5 .
My old dualshock PS4 failed !
v8...@gmail.com <v8...@gmail.com> #96
Now something !
Phantom Proccess killling and similar has purpose to kill apps which eat resources !
It is their purpose !
But Phantom Killing Proccess and similar gang are draining proccesor and BATERY non stop ,
searching for apps to kill !!
They swap one evil for maybe worse !
Google own killing proccesses are killing proc and batery !!!
da...@gmail.com <da...@gmail.com> #97
da...@gmail.com <da...@gmail.com> #98
A partial fix in development config doesn't solve this. Some versions ago,we could see bad apps in termux, see the consumption of CPU, today, the process in background are obscure, also the temps ( only with game mode plugins we could see the real value) . This os is more and more obscure, and we couldn't wait 1 year and another android version to partially solve this.
With this problem and the gamepad accesibility version in Android 11, you take a war for advanced gaming users, making to go out,and you lost most advanced users for years. Why not you didn't make the gamepad support mandatory and impulse more serious gaming that doesn't seem a gambling machine? Only a few console ports in play store are really interesting.
v8...@gmail.com <v8...@gmail.com> #99
v8...@gmail.com <v8...@gmail.com> #100
Google does not want us to switch anything !
They dont care !
They following only their own agenda and users are not RELEVANT !
ev...@gmail.com <ev...@gmail.com> #101
, just to find out is useless becouse of this phantom issues!! Well back to the box and ask for my money back!!
mi...@gmail.com <mi...@gmail.com> #102
ke...@gmail.com <ke...@gmail.com> #103
Phones are no longer "consumption devices" where we subscribe to overpriced media only to watch ads. These devices are now full fledged development tools. If I turn on "developer tools" it should be clear that I know what I am doing and am willing to take risks to play with toggles and options.
For now, I will use the ADB command and wireless debugging, but it is a shame I need to keep setting this simply to bring up my mobile desktop to get work done.
ra...@gmail.com <ra...@gmail.com> #104
Am I reading correctly that this commit is merged in android master:
"Add settings to toggle the phantom process monitoring in dev options
For power users, the monitoring on phantom processes could be turned
off from the Settings->Developer Options->Feature flags."
The commit date is Dec 14, 2021.
source:
Does anyone know if this is in android 13 for normal user builds with developer options enabled?
Thanks
ga...@gmail.com <ga...@gmail.com> #105
Sent from Nine
________________________________
From: buganizer-system@google.com
Sent: Tuesday, August 16, 2022 9:33 AM
To: b-system+-425673847@google.com
Cc: gabrielstangl65@gmail.com
Subject: Re:
Replying to this email means your email address will be shared with the team that works on this product.
Changed
ra...@gmail.com added
I'm not familiar with the site
Am I reading correctly that this commit is merged in android master:
"Add settings to toggle the phantom process monitoring in dev options
For power users, the monitoring on phantom processes could be turned
off from the Settings->Developer Options->Feature flags."
The commit date is Dec 14, 2021.
source:
Does anyone know if this is in android 13 for normal user builds with developer options enabled?
Thanks
_______________________________
Reference Info: 205156966 Phantom Process Killing In Android 12 Is Breaking Apps
component: Android Public Tracker
status: Assigned
reporter: ag...@gmail.com
assignee: jj...@google.com
cc: ag...@gmail.com, jj...@google.com
type: Bug
priority: P3
severity: S3
retention: Component default
Generated by Google IssueTracker notification system
You're receiving this email because you are subscribed to updates on Google IssueTracker
Unsubscribe from this issue.
ni...@gmail.com <ni...@gmail.com> #106
It was always ironic that you can't develop for Android on Android. It now appears that's intentional.
I use my Galaxy Note 10+ as my daily PC thanks to Samsung DeX and a large 34" ultrawide USB-C monitor. I had aspirations to upgrade to the Fold 4 with 12L to finally get away from Windows once and for all. Instead I've now ended up buying a new Windows ultra-portable laptop (GOD Win Max 2) as I can clearly see I shouldn't bet on Android going forward.
The fact that we have phones that are as powerful as an average ultrabook but are locked down beyond any semblance of user control short of rooting is just embarrassing. Even a Chromebook, a system designed for elementary school children, is more capable at this point.
Thanks for helping make my choice to stop pursuing the dream of convergence an easy one, Google.
Listen to your users.
ra...@gmail.com <ra...@gmail.com> #107
ag...@gmail.com <ag...@gmail.com> #108
Updated instructions for disabling killing of phantom process and excessive cpu usage processes has been uploaded to
The gist at
The fix is already available in Android 12L and 13 in AOSP with the settings_enable_monitor_phantom_procs
settings flag added in 09dcdad
Settings icon
-> About
and it should show the current value of MONITOR_PHANTOM_PROCS
under Software
info section on Android 12+
devices and will be marked <unsupported>
if its not supported in current android build. It should also show in next F-Droid release v0.119.0
.
da...@gmail.com <da...@gmail.com> #109
ga...@gmail.com <ga...@gmail.com> #110
st...@gmail.com <st...@gmail.com> #111
qu...@gmail.com <qu...@gmail.com> #112
ge...@gmail.com <ge...@gmail.com> #113
mv...@gmail.com <mv...@gmail.com> #114
ha...@gmail.com <ha...@gmail.com> #115
There's also a switch for this in developer options but not in OEM Android versions. The f?
Was waiting for a year to get a fix for this, as more or less promised on the below page. And then it comes and is a really bad solution.
gr...@gregoryhorne.ca <gr...@gregoryhorne.ca> #116
h4...@gmail.com <h4...@gmail.com> #117
Come on Google, get this fixed or at least let the users choose to disable certain applications from being killed.
v8...@gmail.com <v8...@gmail.com> #119
What Google wants is to buy new phone every month .
All those app killers are there just to push you to buy new phone .
Users are for money milking , cattle .
jj...@google.com <jj...@google.com> #120
Please check the Android 14 beta release, there is a toggle in Settings-> Developer Options -> Disable child process restrictions
ag...@gmail.com <ag...@gmail.com> #121
Thanks a lot for the addition!
It sets persist.sys.fflag.override.settings_enable_monitor_phantom_procs
to false
, which normally requires root. Current state can be checked with getprop persist.sys.fflag.override.settings_enable_monitor_phantom_procs
. Note that disabling Developer Options will enable restrictions again as toggle state will be reverted. Will update the docs when I get time.
mi...@gmail.com <mi...@gmail.com> #122
da...@gmail.com <da...@gmail.com> #123
ag...@gmail.com <ag...@gmail.com> #124
Can always run command in docs over adb
or root
once for such cases.
co...@gmail.com <co...@gmail.com> #125
| index | [npm-run-all] | [run-s] | [run-p] | [Node API] |
|-------|---------------|---------|---------|------------|
# npm-run-all
[
[
[
[
[
[
A CLI tool to run multiple npm-scripts in parallel or sequential.
## 猡达笍 Motivation
- **Simplify.** The official `npm run-script` command cannot run multiple
scripts, so if we want to run multiple scripts, it's redundant a bit. Let's
shorten it by glob-like patterns.<br>
Before: `npm run clean && npm run build:css && npm run build:js && npm
run build:html`<br>
After: `npm-run-all clean build:*`
- **Cross platform.** We sometimes use `&` to run multiple command in
parallel, but `cmd.exe` (`npm run-script` uses it by default) does not
support the `&`. Half of Node.js users are using it on Windows, so the use
of `&` might block contributions. `npm-run-all --parallel` works well on
Windows as well.
## 馃捒 Installation
```bash
$ npm install npm-run-all --save-dev
# or
$ yarn add npm-run-all --dev
```
- It requires `Node@>=4`.
## 馃摉 Usage
### CLI Commands
This `npm-run-all` package provides 3 CLI commands.
- [npm-run-all]
- [run-s]
- [run-p]
The main command is [npm-run-all].
We can make complex plans with [npm-run-all] command.
Both [run-s] and [run-p] are shorthand commands.
[run-s] is for sequential, [run-p] is for parallel.
We can make simple plans with those commands.
#### Yarn Compatibility
If a script is invoked with Yarn, `npm-run-all` will correctly use Yarn to
execute the plan's child scripts.
### Node API
This `npm-run-all` package provides Node API.
- [Node API]
## 馃摪 Changelog
-
## 馃嵒 Contributing
Welcome鈾�
### Bug Reports or Feature Requests
Please use GitHub Issues.
### Correct Documents
Please use GitHub Pull Requests.
I'm not familiar with English, so I especially thank you for documents'
corrections.
### Implementing
Please use GitHub Pull Requests.
There are some npm-scripts to help developments.
- **npm test** - Run tests and collect coverage.
- **npm run clean** - Delete temporary files.
- **npm run lint** - Run ESLint.
- **npm run watch** - Run tests (not collect coverage) on every file change.
[npm-run-all]: docs/npm-run-all.md
[run-s]: docs/run-s.md
[run-p]: docs/run-p.md
[Node API]: docs/node-api.md
On Mon, Jan 29, 2024, 8:45 PM <buganizer-system@google.com> wrote:
nk...@gmail.com <nk...@gmail.com> #126
fa...@gmail.com <fa...@gmail.com> #127
=
[Deleted User] <[Deleted User]> #128
This change has far more implications than annoying hobbyist/poweruser or making poor children in Uganda unable to learn how to program. In my opinion, an exemption in developer settings is not enough, let alone the fact that enabling developer settings makes many daily-used apps like banking apps refuse to work.
Like, it could possibly break VPN apps as well, because VPN apps may also launch native processes to handle the traffic.
Just take Shadowsocks-Android as an example.
In case you are not familiar with what Shadowsocks is, you may check the Outline VPN project (hint: Jigsaw is a company started by Google):
(tldr: Shadowsocks is a prominent censorship circumvention project, and the protocol of Shadowsocks was later adopted by Jigsaw as the Outline VPN project)
Look at the code, Shadowsocks-android is launching its critical traffic handling process in the exact "phantom" way:
fun start() {
process = ProcessBuilder(cmd).directory(Core.deviceStorage.noBackupFilesDir).start()
}
To me, this change essentially attempts to drive native processes/executables away from Android ecosystem, which breaks many legitimate usages, which might be far beyond VPN apps or Termux.
Please reconsider this.
co...@gmail.com <co...@gmail.com> #129
Get Outlook for Android<
________________________________
From: buganizer-system@google.com <buganizer-system@google.com>
Sent: Sunday, June 9, 2024 3:59:02 PM
To: b-system+854701047@google.com <b-system+854701047@google.com>
Cc: cowgirlupsweett@gmail.com <cowgirlupsweett@gmail.com>
Subject: Re:
Replying to this email means your email address will be shared with the team that works on this product.
Changed
ac...@googlemail.com added
This change has far more implications than annoying hobbyist/poweruser or making poor children in Uganda unable to learn how to program. In my opinion, an exemption in developer settings is not enough, let alone the fact that enabling developer settings makes many daily-used apps like banking apps refuse to work.
Like, it could possibly break VPN apps as well, because VPN apps may also launch native processes to handle the traffic.
Just take Shadowsocks-Android as an example.
In case you are not familiar with what Shadowsocks is, you may check the Outline VPN project (hint: Jigsaw is a company started by Google):
(tldr: Shadowsocks is a prominent censorship circumvention project, and the protocol of Shadowsocks was later adopted by Jigsaw as the Outline VPN project)
Look at the code, Shadowsocks-android is launching its critical traffic handling process in the exact "phantom" way:
fun start() {
process = ProcessBuilder(cmd).directory(Core.deviceStorage.noBackupFilesDir).start()
}
To me, this change essentially attempts to drive native processes/executables away from Android ecosystem, which breaks many legitimate usages, which might be far beyond VPN apps or Termux.
Please reconsider this.
_______________________________
Reference Info: 205156966 Phantom Process Killing In Android 12 Is Breaking Apps
component: Android Public Tracker<
status: Assigned
reporter: ag...@gmail.com
assignee: jj...@google.com
cc: ag...@gmail.com, jj...@google.com
type: Bug
access level: Default access
priority: P3
severity: S3
retention: Component default
Generated by Google IssueTracker notification system.
You're receiving this email because you are subscribed to updates on Google IssueTracker
Unsubscribe from this issue.<
co...@gmail.com <co...@gmail.com> #130
ha...@gmail.com <ha...@gmail.com> #131
Thank you
jb...@gmail.com <jb...@gmail.com> #132
Thanks
Description
Phantom Processes
Android 12 via and updated via has added the mechanism to monitor forked child processes started by apps and kills them if more than the default
15755084
5706277f
32
are found running.The app or phantom processes may also be killed if they use excessive CPU, which was done previously too, but only for app process .
This
32
process limit is for all apps combined and not per app.Check here .
PhantomProcessList
commit historyI am one of the maintainers for the and the new changes have completely broken our app's core functionality and affects other similar apps as well, like Tasker. The issue was opened by a Pixel 3a user in which I found out about this after going through android source. This change is neither listed in android changes list nor behavior changes and was done silently.
termux-app
termux-app#2366
12
The problem is that if more than .
32
processes are running, then processes belonging to termux app greater than the limit will get trimmed even if battery optimizations are disabled for the app. Moreover, since the limit is for all apps combined, if termux tries to run just1
process and is in background and another (buggy) app has>= 32
processes running, and at the time of killing, the other app'sapp
process has a lower oom adj than termux'sapp
process (not the oom adj of the child processes themselves), the single process of termux would get killed first byPhantomProcessList.trimPhantomProcessesIfNecessary()
If there are buggy apps running, like
McAfee Security
app currently, it will not let apps like Termux run any processes at all for long.Foreground oriented apps will always be given higher priority, but an app that mostly works in background does not mean its unimportant for the user..
Current design can also be abused by malicious apps by spawning unneeded processes.
I have also written a very detailed comment about this and how it affects apps trying to run background commands. The main sections to check would be the
McAfee app gone crazy
,The "unfair" advantage for foreground oriented apps
,Buggy and malicious apps
andImprovements in heuristics and exemptions for apps
. Some other sections from it are referred below too. I didn't copy all that info again here since its too long and Github has better markdown support, considering collapse sections are not working here. By I can do it if it's requested.Steps to reproduce the problem
Install the termux apps from Github or F-Droid as per installation instructions . F-Droid direct link is https://f-droid.org/en/packages/com.termux . After installing the app, open it and let bootstrap installation to finish.
Run the following command and put termux in background and connect or disconnect the charger.
You can monitor cpu usage with
top
command and runkillall sha256sum
to kill the processes started.What happened
When you return to Termux app, it should say
[Process completed (signal 9) - press Enter]
because the mainlogin
bash
shell should have gotten killed and any other older processes above32
. Sometimesbash
gets killed as soon as one runs the loop while Termux is still in foreground, sometimes after switching to another app and come back, and sometimes takes a few minutes depending on when phantom process killing is scheduled. The connecting or disconnecting the charger works instantly, as perBattery power changes
trigger mentioned in theHow phantom process killing gets scheduled?
section.Note that
bash
was started withpid
5683
andlogcat
logs the killing. Thesha256sum
commands below are CPU intensive but only their count matters for the killing. Thebash
process would barely use any CPU but still get killed first since its the oldest. Check theHow are phantom processes killed?
section for more info on how killing is prioritized.Transcript to start
1
bash process +40
sha256sum processesLogcat showing
9
phantom processes trimmedRemaining
32
tracked phantom processesWhat you think the correct behavior should be
Copied the
Improvements in heuristics and exemptions for apps
section...Neither trimming nor excessive CPU killing, nor empty process killing (including possibly daemon, like termux-app/#2015 , termux-boot/#5 ) should be done for apps that have battery optimizations disabled. A user explicitly granted an app the permission to "use battery", android shouldn't be killing its processes, unless under memory pressure, or at the very least shouldn't prioritize it. That should be like the whole point of disabling battery optimizations. Adding this to android OS should solve most of the concerns.
sshd
,And if trimming needs to be done, the heuristics should improve. It should have some minimum allowed limit of phantom processes for each app below which they are all ignored and also a max allowed limit per app that should be something like
max_phantom_processes/3
(or whatever the android overlords think is ideal) above which trimming of the phantom processes of that specific app is prioritized before starting to kill processes of other apps, so that foreground oriented, malicious and buggy apps don't affect other apps too much.If I hadn't asked OP for the logs, we wouldn't have known that McAfee was causing so much trouble for other apps and who knows how long it has been doing it. And OP was actually capable of reporting and providing logs, but an average user wouldn't be, and from their perspective, their apps would just be getting killed because had knowingly or blindly installed a buggy app from playstore. And even if they reported (without logs), devs wouldn't be able to reproduce the issue on their device, since they wouldn't likely have a buggy app installed, so this kinda issues will be harder to solve for devs and will have nothing to do with their code. The OS should protect users from that, even without them having to check
logcat
anddumpsys
output.Moreover, total
32
processes limit of all apps combined is too low. That can easily be hit during what one would consider normal conditions and not excessive. Just running2-3
terminal sessions, each with optional terminal multiplexer (tmux
) and then actually running some commands in them or just a script that divides work with background jobs (command &
), plus some processes started incrementally as or for plugins, liketermux-api
ortermux-tasker
and you are easily looking at more than15
to30
processes for just Termux. Now add some user running some servers in Termux or add Tasker with its profiles and tasks, plus any other app, and32
limit is hit instantly and processes getting trimmed, and some important work or data being lost.Questions
adb
way to disable the killing can't be expected to be done by all our users. Moreover, completely disabling phantom killing will allow apps going crazy with background processes to consume lot of battery and android should provide a per app exemption instead, so that only specific apps can be exempted and phantom killing still applies to other apps. This way user experience of (power) users is not harmed.What are the risks with disabling phantom process killing?
section, but best ask the android devs that question.Thanks,
agnostic-apollo
Termux App Info
APP_NAME:
Termux
PACKAGE_NAME:
com.termux
VERSION_NAME:
0.117
VERSION_CODE:
117
UID:
10147
TARGET_SDK:
28
IS_DEBUGGABLE_BUILD:
true
APK_RELEASE:
Github
SIGNING_CERTIFICATE_SHA256_DIGEST:
B6DA01480EEFD5FBF2CD3771B8D1021EC791304BDD6C4BF41D3FAABAD48EE5E1
Device Software Info
OS_VERSION:
5.10.43-android12-9-00031-g02d62d5cece1-ab7792588
SDK_INT:
31
RELEASE:
12
ID:
SE1A.211012.001
DISPLAY:
sdk_gphone64_x86_64-userdebug 12 SE1A.211012.001 7818354 dev-keys
INCREMENTAL:
7818354
SECURITY_PATCH:
2021-11-05
IS_DEBUGGABLE:
1
IS_EMULATOR:
1
IS_TREBLE_ENABLED:
true
TYPE:
userdebug
TAGS:
dev-keys
Device Hardware Info
MANUFACTURER:
Google
BRAND:
google
MODEL:
sdk_gphone64_x86_64
PRODUCT:
sdk_gphone64_x86_64
BOARD:
goldfish_x86_64
HARDWARE:
ranchu
DEVICE:
emulator64_x86_64_arm64
SUPPORTED_ABIS:
x86_64, arm64-v8a