- Before silencing the logs, ensure security logs are whitelisted
- Only touch persist.log.tag properties if they need to be, add
stacking to the property.
- Clear persist.logd.size property when at default setting
Bug: 26178938
Change-Id: I8fdb040062dc9cbb23d7bc3c117d96ff8550c132
A session keeps in ApplicationsState list. The fragment don't release
the session when it is destroyed. The cause of out of memory is that the
session list is increased, but it can't be released.
Change-Id: I23635610c9fdfb8a3423299a91cf9b11cb5cdb65
Signed-off-by: daqiangx <daqiangx.li@intel.com>
File.java will return the total size in bytes of the partition
containing the path, and if the path does not exist,
it will return 0.
Change-Id: I134d4ec787b475e38bb37b4386bafcc419971c1e
The privilege for an app to write to the system settings is protected
by an app-op signature permission. App-op permissions are special: if
the app-op is deny/allow we deny/allow write access; if the app-op is
default holding the permission determies write access. The settings
code assumes that CHANGE_NETWORK_STATE is an app op permission
(system|appop) while it is a normal permission which any app gets by
declaring it used in the manifest.
The side effect is that the state of the toggle in the UI for write
system settings will initially be in the wrong state if the app uses
both WRITE_SETTINGS and CHANGE_NETWORK_STATE. However, the code in
the public API an app uses to check write settings access would return
the opposite since it checks the WRITE_SETTINGS permission and its
app op. Hence, if an app requires write settings to start the user
will see in the settings UI it has access but the app will not have
access, so the app would prompt the user to allow write settings.
The non-obvious fix is for the user to toggle the setting off and on
to get the app op in the right state and be able to launch the app.
bug:25843134
Change-Id: I3d726a66c7f9857bc7dbd5946fdbb8f340c6eb4d
(cherry picked from commit 356fb2d10d)
Add a UsbDisconnectedReceiver to listen usb state event, and hide
the usb mode chooser dialog if usb disconnected.
Change-Id: I871f56cb5a310e20950926180d9747dd9fad9754
Signed-off-by: Du, Changbin <changbin.du@intel.com>
Signed-off-by: Zhiquan Liu <zhiquan.liu@intel.com>
The eject sdcard warning page shows incomplete texts
in some languages (german) and it is not apparant that
that you can scroll to see the text.
The layout is divided into three parts, the button
and one blank line, and the text. The text and the
blanke space will have equal parts of the screen
since they have the same weight. Because of this the
(complete) text is not shown in som languages.
Remove the blank part and let the text use the whole
screen.
Change-Id: Id8fd88fc6c0aa6105d64c100e3365cd9b00bf851
The privilege for an app to write to the system settings is protected
by an app-op signature permission. App-op permissions are special: if
the app-op is deny/allow we deny/allow write access; if the app-op is
default holding the permission determies write access. The settings
code assumes that CHANGE_NETWORK_STATE is an app op permission
(system|appop) while it is a normal permission which any app gets by
declaring it used in the manifest.
The side effect is that the state of the toggle in the UI for write
system settings will initially be in the wrong state if the app uses
both WRITE_SETTINGS and CHANGE_NETWORK_STATE. However, the code in
the public API an app uses to check write settings access would return
the opposite since it checks the WRITE_SETTINGS permission and its
app op. Hence, if an app requires write settings to start the user
will see in the settings UI it has access but the app will not have
access, so the app would prompt the user to allow write settings.
The non-obvious fix is for the user to toggle the setting off and on
to get the app op in the right state and be able to launch the app.
bug:25843134
Change-Id: I2da4eec1c3574bd6aef9ab968c9deb148536cb0a
