WAI
Status Update
Comments
nn...@google.com <nn...@google.com> #2
Proof of concept demo on Github: https://github.com/casperbang/MissingNonLocalizedDrawableCrash
No problem compiling, lint'ing or running the app on a Danish device. Crash when running on a device set to any other locale.
No problem compiling, lint'ing or running the app on a Danish device. Crash when running on a device set to any other locale.
tl...@gmail.com <tl...@gmail.com> #3
I should probably generalize the translation detector's extra strings check, which is exactly this issue (but currently limited to strings checks).
mi...@gmail.com <mi...@gmail.com> #4
Finally got to this one. This is implemented for 3.2 canary 7 (along with a bunch of other fixes; it can now run the translation checks on the fly in the IDE; there are some quickfixes, etc.)
Here's what I get on the sample project:
> Task :app:lintDebug
/home/tnorbye/AndroidStudioProjects/bugs/MissingNonLocalizedDrawableCrash/app/src/main/res/drawable-da-xxxhdpi/sticker_ci.png: Error: The drawable "sticker_ci" in drawable-da-xxxhdpi has no declaration in the base drawable folder or in a drawable-densitydpi folder; this can lead to crashes when the drawable is queried in a configuration that does not match this qualifier [MissingDefaultResource]
Explanation for issues of type "MissingDefaultResource":
If a resource is only defined in folders with qualifiers like -land or -en,
and there is no default declaration in the base folder (layout or values
etc), then the app will crash if that resource is accessed on a device
where the device is in a configuration missing the given qualifier.
As a special case, drawables do not have to be specified in the base
folder; if there is a match in a density folder (such as drawable-mdpi)
that image will be used and scaled. Note however that if you only specify
a drawable in a folder like drawable-en-hdpi, the app will crash in
non-English locales.
There may be scenarios where you have a resource, such as a -fr drawable,
which is only referenced from some other resource with the same qualifiers
(such as a -fr style), which itself has safe fallbacks. However, this still
makes it possible for somebody to accidentally reference the drawable and
crash, so it is safer to create a default dummy fallback in the base
folder. Alternatively, you can suppress the issue by adding
tools:ignore="MissingDefaultResource" on the element.
(This scenario frequently happens with string translations, where you might
delete code and the corresponding resources, but forget to delete a
translation. There is a dedicated issue id for that scenario, with the id
ExtraTranslation.)
1 errors, 0 warnings
Thanks for the report!
Here's what I get on the sample project:
> Task :app:lintDebug
/home/tnorbye/AndroidStudioProjects/bugs/MissingNonLocalizedDrawableCrash/app/src/main/res/drawable-da-xxxhdpi/sticker_ci.png: Error: The drawable "sticker_ci" in drawable-da-xxxhdpi has no declaration in the base drawable folder or in a drawable-densitydpi folder; this can lead to crashes when the drawable is queried in a configuration that does not match this qualifier [MissingDefaultResource]
Explanation for issues of type "MissingDefaultResource":
If a resource is only defined in folders with qualifiers like -land or -en,
and there is no default declaration in the base folder (layout or values
etc), then the app will crash if that resource is accessed on a device
where the device is in a configuration missing the given qualifier.
As a special case, drawables do not have to be specified in the base
folder; if there is a match in a density folder (such as drawable-mdpi)
that image will be used and scaled. Note however that if you only specify
a drawable in a folder like drawable-en-hdpi, the app will crash in
non-English locales.
There may be scenarios where you have a resource, such as a -fr drawable,
which is only referenced from some other resource with the same qualifiers
(such as a -fr style), which itself has safe fallbacks. However, this still
makes it possible for somebody to accidentally reference the drawable and
crash, so it is safer to create a default dummy fallback in the base
folder. Alternatively, you can suppress the issue by adding
tools:ignore="MissingDefaultResource" on the element.
(This scenario frequently happens with string translations, where you might
delete code and the corresponding resources, but forget to delete a
translation. There is a dedicated issue id for that scenario, with the id
ExtraTranslation.)
1 errors, 0 warnings
Thanks for the report!
fe...@gmail.com <fe...@gmail.com> #5
What about /proc/interrupts? Is this file still accessible in Android O?
All the sensitive interrupt information can be also read from there in addition to /proc/stat.
All the sensitive interrupt information can be also read from there in addition to /proc/stat.
de...@gmail.com <de...@gmail.com> #6
There is already API in Android to get CPU usage info, starting from API level 24:
HardwarePropertiesManager propertiesManager = (HardwarePropertiesManager)context.getSystemService(Context.HARDWARE_PROPERTIES_SERVICE);
CpuUsageInfo[] cpuUsages = propertiesManager.getCpuUsages();
But only system apps have access to this API, because only system apps can have android.permission.DEVICE_POWER permission, which is needed here.
So, I think, it would be enough to give all apps access to this API to solve the issue.
HardwarePropertiesManager propertiesManager = (HardwarePropertiesManager)context.getSystemService(Context.HARDWARE_PROPERTIES_SERVICE);
CpuUsageInfo[] cpuUsages = propertiesManager.getCpuUsages();
But only system apps have access to this API, because only system apps can have android.permission.DEVICE_POWER permission, which is needed here.
So, I think, it would be enough to give all apps access to this API to solve the issue.
nn...@google.com <nn...@google.com> #7
Re comment #5 : /proc/interrupts is also similarly restricted, as it leaks side channel information about the global state of the device.
Re comment #6 : opening up that API would defeat the intent of these changes. Applications needing per-process CPU information should likely use /proc/self/stat instead of /proc/stat.
Re
te...@gmail.com <te...@gmail.com> #8
Is there another way to get total CPU usage load in Android O now without access to /proc/stat? My app can no longer read CPU usage, and it was one of its main functions.
k....@gmail.com <k....@gmail.com> #9
Ok, having in mind that access to /proc/stat is restricted for a reason, tell me, as a "common user", how to see my CPU usage of device when all of apps stopped working? Having in mind that I OWN this device I MUST have access to this information. If we "common users" want to use our devices for only "facebook/phone/mail" then we can freely go for iOS, there is tons of restrictions already. These devices are first of all computers....
ma...@gmail.com <ma...@gmail.com> #10
On Android O, is there any system app that, as a *common user*, can use to see the total cpu usage?
tl...@gmail.com <tl...@gmail.com> #12
#11. That CPU monitor app, like my own, only shows CPU frequency on Android 8.
CPU clock is unfortunately a poor indicator of processor utilization and battery drain. I recently added clock frequency recording to my own SystemPanel2 app, and have noticed CPU usage and clock frequency can be *inversely proportional* in many cases. They'll line up when you're looking at intense CPU use (e.g. playing a game), but when a user is looking for inexplicable battery drain, CPU clock frequency is more often not useful.
Attached screenshot of SystemPanel2 is on an Android 7 device with root access (required to record CPU usage per-process on 7). Note that during the period of highest CPU utilization and battery drain, the average CPU clock frequency is quite low.
In my opinion there should be a permission-protected but publicly accessible API to retrieve recent CPU usage. Round the values and update it at 2 second intervals, leave out interrupt data, and these side channel attacks are irrelevant.
CPU clock is unfortunately a poor indicator of processor utilization and battery drain. I recently added clock frequency recording to my own SystemPanel2 app, and have noticed CPU usage and clock frequency can be *inversely proportional* in many cases. They'll line up when you're looking at intense CPU use (e.g. playing a game), but when a user is looking for inexplicable battery drain, CPU clock frequency is more often not useful.
Attached screenshot of SystemPanel2 is on an Android 7 device with root access (required to record CPU usage per-process on 7). Note that during the period of highest CPU utilization and battery drain, the average CPU clock frequency is quite low.
In my opinion there should be a permission-protected but publicly accessible API to retrieve recent CPU usage. Round the values and update it at 2 second intervals, leave out interrupt data, and these side channel attacks are irrelevant.
Description
It is no longer possible to determine the CPU utilization of the device.
This has severe negative consequences for system and battery monitoring applications and denies the user the ability to correct problems with his/her device.