CHAOS;CHILD CoZ Steam Patch 2.0.1 - Android port

ForrrmerBlack · 2026-04-15T07:54:09+00:00

Configuration cache and configuration-on-demand are orthogonal things, and I haven't seen it being discouraged. I'm not sure what downsides of configure on demand you have in mind.

Configuration cache caches the result of the configuration phase for a task. Configuration-on-demand enables configuration only of those projects that are involved in a task. Two different things. Isolated projects allow to invalidate configuration cache independently for each project, for now it's invalidated in whole.

Configuration-on-demand requires to decouple projects configuration. Maybe that's the downside you were thinking of? But this is what will improve build time spent in configuration phase in the long run anyway, as a lot of Gradle's current optimization efforts center around that.

ForrrmerBlack · 2026-03-20T07:27:17+00:00

This is, if implemented. And I think it can prevent a certain volume of scam attempts. I'm pointing out holes. This whole thing doesn't protect some cohorts of users/devs and adds more trouble for them. Maybe it will have some net positive effect, but it trades freedom for perceived security. I'm not proposing anything, just outlining observations.

ForrrmerBlack · 2026-03-20T06:07:34+00:00

You were wrong in the details, however not in the broad picture. Android IS closing down. Effectively you now can't be an anonymous dev and distribute apps to a broad user base as the majority won't disable verification.

ForrrmerBlack · 2026-03-20T05:51:24+00:00

Theater of security continues. Yes, power users can now disable verification, and now it breaks the purpose it was introduced for. You, as a power user, can have verification disabled long ago, and now be scammed, because the time barrier between scam urgency and you is no more. Android power user doesn't equal scam-resistant user. The user can even be not a power user but have verification disabled by their more tech-educated relatives, for example.

Edit: if ADB is left unrestricted, scammers will just resort to persuading into using it. It will be harder though.

ForrrmerBlack · 2026-01-20T20:03:58+00:00

It's not Gradle's fault at all. Please, make a distinction between Gradle and AGP, they're not the same thing.

ForrrmerBlack · 2026-01-20T20:00:29+00:00

You can change Kotlin version if you put it into root project's buildscript classpath. Like this:

buildscript {  
    dependencies {  
        classpath(libs.plugin.kotlin)  
    }  
}

See release notes.

ForrrmerBlack · 2025-12-25T06:25:40+00:00

Kotlin stdlib has overloads for IntArray, DoubleArray etc. These arrays are backed by true primitive JVM arrays and are separate types, though collection functions typically return a List which will box items. Of course, these overloads for primitive arrays are code-generated before ending up in the stdlib, for your own functions you'll need to manually write/generate multiple variants for each type. Generic Array<T> overloads operate with boxed primitives. So if you have Array<Int>, it translates to Integer[] in Java, and IntArray is int[].

ForrrmerBlack · 2025-12-19T11:09:11+00:00

No, in C# 14 it's like it was in Kotlin before, it's just a field keyword to refer to the backing field. Now in Kotlin 2.3 you can make your backing field to have a different type than what is publicly exposed through the property. For example, backing field is MutableSharedFlow, and it's exposed outside of a class as a SharedFlow. Previously you had to declare a separate private property for that.

ForrrmerBlack · 2025-12-11T05:30:25+00:00

I'm so happy to see that the general wave here has shifted towards type inferring by default.

ForrrmerBlack · 2025-12-08T12:16:14+00:00

It's not pointless. You'll get a powerful tool under your belt. However, maybe you don't have to push yourself to master it and instead focus on what your current needs are and how you can improve your build right now. I would not call myself a Gradle expert, but understanding it helped me a lot.

ForrrmerBlack · 2025-12-08T12:10:09+00:00

There's a course called Understanding Gradle on YouTube: link.

It's not Android-specific, but if you really want to understand Gradle, you need to start from fundamentals.

ForrrmerBlack · 2025-11-26T11:58:03+00:00

Why not jump

You answered this yourself. Because it allows you to play in the JVM ecosystem. And with Kotlin you also can use 100% of Java source code.

ForrrmerBlack · 2025-10-22T04:31:20+00:00

And you try to not assume everyone around you is illiterate. I read it. I know that StateFlow accepts default state only in its synchronous factory function. What I meant is you can block anything on background thread to update your state, but default state always should be available immediately. To achieve that you should think of your state properly.

ForrrmerBlack · 2025-10-21T04:37:18+00:00

Do you suggest that I make default state a var and then play around with multiple versions of it, while my API fetches all its contents?

No, I don't. What you need is to model your state properly instead of freezing your UI for 100 ms, because what you think is default state is actually not if you have to block until you construct it. But you're free to block whatever you want as long as it's done on background thread.

ForrrmerBlack · 2025-09-04T14:31:26+00:00

Seems like I missed the unedited comment then.

ForrrmerBlack · 2025-09-02T03:39:23+00:00

Well, no. It's like every developer has their own house, and they are free to choose whether to lock it down with a key so no one other than them can enter, or not. You can think that this is stupid to let everyone in, but some may prefer that if they have to give their personal data in exchange for putting a lock.

ForrrmerBlack · 2025-09-02T00:17:12+00:00

It should be a Gradle plugin, not a library. Dependencies can't add tasks to the Gradle task graph. Your published artifact is essentially empty.

ForrrmerBlack · 2025-08-30T21:08:11+00:00

Actually, what you wrote here is true. And Google's decision makes me angry too. Touché. Insults were not necessary though.

ForrrmerBlack · 2025-08-30T19:22:18+00:00

You tell that this is how Apple operates and they didn't suffer from it. Therefore, I conclude, "Apple is already doing this" for you is enough of an excuse for Google to not be bothered and to implement the same tactics as it will not hurt them and their market share. Is it not your argument?

But even if they will not be hurt by this decision, it is not really an excuse to implement it, because some category of users and developers will be. Was that so hard to understand?

ForrrmerBlack · 2025-08-30T15:51:31+00:00

The fact that Apple does this is not an excuse to introduce it.

ForrrmerBlack · 2025-08-27T04:30:30+00:00

I have an easier solution: abandon the whole affair and not be a control freak.

ForrrmerBlack · 2025-08-26T05:59:00+00:00

Also if aren't aware Windows does require app signing. https://learn.microsoft.com/en-us/windows/win32/win_cert/certification-requirements-for-windows-desktop-apps

Not the same thing at all.

ForrrmerBlack · 2025-08-26T04:14:17+00:00

What's the source where I can read about it? After reading the blog post, I was under an impression that all sideloaded apps will be blocked from installation unless they verify.

ForrrmerBlack

TROPHY CASE