I'm working in a custom AOSP build for which I made an overlay that changes the device default theme. I've put those overlays in:
device/overlay/framework/base/core/res/res
Now I'd like to make a different overlay for the same build in such a way that changing a property will change the overlay that is applied.
So for example I set
setprop persist.brand brand1
And i see overlay1, then:
setprop persist.brand brand2
and see overlay2.
I've been digging into RRO and was able to change some overlays with custom apks but I have no clue how to tie that to a system property.
EDIT:
I found that I can achieve similar results by compiling rro apks using
include $(BUILD_RRO_PACKAGE)
in the Android.mk.
What I noticed is that in the build_rro_package.mk there is a comment that says
## Set LOCAL_RRO_THEME to the theme name if the package should apply only to
## a particular theme as set by ro.boot.vendor.overlay.theme system property.
What I understand is that I can group many rro packages into the same LOCAL_RRO_THEME name and then activate or deactivate them together using the ro.boot.vendor.overlay.theme property. If this is correct then it's exactly what I was looking for
The problem I face now is that when I set LOCAL_RRO_THEME with a different name than the LOCAL_PACKAGE_NAME the overlay won't show when I list them with:
cmd overlay list
This doesn't make much sense, but maybe I'm doing something wrong?
which AOSP version are you working on? There's a runtime overlay feature in AOSP 9(though Google has not publish the document yet, but it's there). On the earlier version, this can't be done because overlay system is done on compile time. If you really want to change resources on the runtime, you need to modify the framework, especially PackageManagerService
Related
I have an SVG asset of a map, in which I have to change the color of some cities depending on the results of a network call. On the web, one normally would add a class to each path, give it some CSS, and toggle that class using JavaScript.
How can I achieve the same effect in flutter?
This can be done with the new version of jovial_svg. It supports embedded stylesheets, so you can use CSS exactly as suggested. Of course, you'd need to re-parse the SVG whenever there's a change, but that's not a big deal here.
Alternately, if it's just one set of cities, you could use SVG's currentColor, and set that value in the appropriate ScalableImage factory. But for your use case, CSS seems like the better way to go.
NOTE: At this exact moment, CSS support is in pre-release, but it should be formally released as 1.1.4 within a couple of days. In the meantime, see https://pub.dev/packages/jovial_svg/versions/1.1.4-rc.3
I am new in Unity and there is something looks weird to me. I created a UnlitTextureYUV.shader file then I use it in my script like this
...
meshRenderer.material = new Material(Shader.Find("UnlitTextureYUV"));
...
Then in editor I click on run button and I see that everything is working properly, ok. Then I click File->Build&Run and I get an error ArgumentNullException that means shader not found.
I tried to find out what is going on and found such answer on Unity community
https://answers.unity.com/questions/1147277/textures-from-local-works-in-editor-missing-in-bui.html
As far as I understand in order to use shaders in build dynamically I need to create dummy material add texture to it and even create dummy object (disabled) and add this material to this object. In this order my shader will be included in build and I will be able to find it dynamically in code by invoke this method Shader.Find("UnlitTextureYUV").
Question is - is there more straight way to include shader in build? Why I need to create dummy objects in order to include this file in build? Or I miss something?
You have to add all your shaders to Unity's 'Always included shaders' list in the
graphic settings.
In GTK3 there was a property on the Gtk.Window class called window-position. By setting this property to Gtk.WindowPosition.CENTER it was possible to tell the window to render in the center of the screen.
In GTK4 this property has been removed. How to achieve the same behavior in GTK4, i.e. how to make the main window of my application to be rendered in the center of the screen?
I checked the migration guide but I couldn't find the solution.
There is no replacement API, since it can't possibly work cross-platform, so it is broken API by definition. As such, it was removed.
For example: this is impossible to implement when running on top of a Wayland session, since the protocol doesn't allow getting/setting global coordinates. If you still want to have something similar working, you'll have to call the specific platform API (for example, X11) for those platforms that you want to support.
I have been grepping through Xamarin's source all morning and can't find out what renderer / VisualElement is responsible for either platform's StackLayout. What is the source that converts a LinearLayout to a platform specific view?
Yes, StackLayoutRenderer is what everyone expects Xamarin to do the trick. However, there is no such in Xamarin.
Xamarin handles the native conversion of certain layouts in the ViewRenderer<TView, TNativeView> itself. They are mapped to the corresponding NativeViews. As you mentioned there are no explicit files that I could either see to be sure or claim on it. Ever since I started working in Xamarin, am also not sure about this.
However, I believe the StackLayout is internally mapped to either the RelativeLayout or ViewGroup which I could confirm by seeing the below VisualTree. I got this tree when loading an entry and a label inside a StackLayout.
Maybe, have a look at the ViewRenderer and VisualElementRenderer class files in each native renderers to have an idea.
according to the docs, Android uses View and iOS uses UIView
Firefox addon. I'm porting an existing addon to a restartless one. I have a panel with a lot of UI elements (mostly boxes/description and images) in it, and it is very convenient for me to define the panel elements in an XUL overlay file. I will have lots of bloated js code if I don't.
The panel element (parent) itself is created in code dynamically, and then I use loadOverlay, wait for the 'merged' event and then append the panel element's children from the overlayed document. I also make sure that the elements are cleaned up upon a remove.
However, using overlays will most probably won't pass an AMO review. And some of the reasons I think are :
In most cases overlay elements will cause problems while removing (eg: toolbar buttons remembering their positions etc.)
There are problems with attaching js/css files in an overlay file.
loadOverlay is buggy (496320, 330458)
And here are my inferences :
loadOverlay() API itself is not deprecated - in fact it is 'not frozen and may change later' - which means possibly it will be use-able in future.
The bug that a second overlay load fails, is not applicable in my case, as I don't initialize without an overlay merge.
Using static overlay for preference windows etc. is perfectly acceptable as of now.
The panel in my case behaves a lot like a preference window (which is brought up on demand and cleaned up upon addon removal)
I don't have any js/css attached to the overlay, nor any event listeners for the elements. The overlay is only used to define boxes and description text - nothing more.
So considering these, is it acceptable to use overlays and loadOverlay() for a restartless addon ? If not, is there an alternative ?
About overlays, by checking source code of restartless addon that extend existing addon (like ehh), I see the overlay.xul is auto merged with the existing addon's. So it shouldn't be a problem to use overlay.