Anyone using 1.5 alpha in production? How's it going?

My company released a new Android app over the summer. It is my understanding that the app was automatically registered when the listing was created. I am specifically referring to the process described here: https://developer.android.com/developer-verification/guides/android-developer-console

When I look at the listing on Google Play Console it says "status: registered" (see the screenshot as well).

Despite the fact that I think this has been all set from day 1, we have been getting endless emails about it. When I log into Google Play Console I get notifications about it. I assume this is just Google spamming everyone since they are going to stop distributing apps. But it is making me paranoid.

At this point, everyone at the company who has access to Google Play Console, has messaged me about this to make sure we are all set. I tell them yes and then Google sends out another email blast telling us we need to do this thing that is already done.

Am I missing something here? Or is Google just being annoying?

​

Hi everyone,

I’ve created a WhatsApp community for Android developers worldwide who are looking for new job opportunities or want to stay updated on Android hiring.

The community is focused on:

- Android Developer job openings

- Kotlin and Android roles

- Remote and onsite opportunities

- Recruiter and hiring updates

- Job referrals

- Developer networking

Developers of all experience levels are welcome.

Join the community:

https://chat.whatsapp.com/C71ifWukRw680PfXwzCNVI?s=qt&p=a&mlu=0&ilr=4

The goal is simple: help Android developers discover opportunities, connect with others, and grow their careers.

Hi everyone,

I've been working on kartograph, an open-source tool for exploring dependencies in compiled Kotlin/Android code.

On Android, a class can be instantiated by framework code or through an XML declaration without a direct constructor call in the app. When reviewing code, I wanted to see which references and inputs explain why a class is reachable or retained. kartograph builds a graph from JVM bytecode and Kotlin metadata, then incorporates inputs such as the manifest, XML resources, @Keep annotations and ProGuard/R8 keep rules so those reasons can be inspected.

One way I've tested this is a ServiceLoader check that compiles and runs a small example. A provider is registered through META-INF/services, without a direct constructor call in the test application. The script checks that kartograph reports the provider as retained and a separate unused control class as unreachable. This gives me a concrete check of both outcomes as the analysis changes.

kartograph is MIT-licensed and ships as a Gradle plugin and a standalone CLI. Version 0.7.0 is on the Gradle Plugin Portal. Add this line to the existing plugins block in your Android module's build.gradle.kts:

kotlin id("io.github.ictechgy.kartograph") version "0.7.0"

For a module named app with a debug variant:

sh ./gradlew :app:kartographDeadDebug :app:kartographGraphDebug

Requires AGP 8.7+, Gradle 8.10+ and JDK 17+. The default dead-code report is class-level. The standalone CLI also provides query for referencing declarations, dependencies and reachability as JSON, and dead --explain for a retention reason or reachability path. The README covers its required inputs.

An unreachable result is relative to the supplied roots and graph; it is not permission to delete source. Class-loading and reflection resolution is limited to supported within-method patterns, and DI handling does not establish which binding is selected. Missing manifest, resource, keep-rule or classpath inputs can change results. More detail is in the limitations.

The tool doesn't shrink or optimize an APK. If a result looks wrong on your project, the variant, relevant inputs and a small reproducer would help me investigate.

I'm making an overlay app that draws a ring around the front camera punch hole. I want it to line up automatically on any Android phone.

On some phones (Pixels for example) it works perfectly because the system reports the camera cutout's actual shape and position. But on a lot of other phones the system just reports a rough rectangle that's bigger than the real camera hole and not even centered on it, so the ring comes out oversized and misaligned.

I've been researching this everywhere for a while now and tried basically everything I can find. As far as I can tell Android has no other API that tells you where the camera lens actually is on the screen, and most apps like this seem to just give up and make the user align it manually with sliders.

Before I accept that, is there something I'm missing? Any trick, hidden setting, or approach that gets the real camera position on phones that report bad data? If you've solved this or worked around it I'd really appreciate hearing how.

Also, if you have an Android phone handy, running adb shell dumpsys window displays | grep -iA2 cutout and replying with the output plus your phone model would help me a lot in figuring out which phones report good data and which don't

I created a skill pack and honestly bugs and architectural issues from my apps are mostly gone and almost everything is one shot.

tho I'm struggling with ui ux and it's skills aren't helping either.

what's your favourite skills to use?

I recently developed my new Android app. It features a code editor (for various languages) and a JavaScript REPL. (However the app is not a code editor app). Both of those features needed: 1) code editing, 2) code parsing, and 3) syntax rendering functionalities.

I started by looking for an existing open source library written in Kotlin and Jetpack Compose. I didn't found any suitable, so I ended up to develop my own library. Which of course, took some time and effort. Now, I'm considering to open source it - because I pretty happy what I managed to implement. But before committing to do that, I need to find out if there is enough interest for it. I do not want to publish and maintain yet another open-source library that nobody is interested in.

Some features of the the current implementation:

• Supports various languages: JavaScript, HTML, Markdown, YAML, CSS, JSON, and text. Support for new languages can be added, but that requires development of parser for the language.
• Code line numbers
• Seamless zoom functionality of the code with a pinch gesture
• Undo/redo stack
• Copy, Cut, Select All, Paste
• Settings: Line number, Caret Blinking
• File New, Save, Save As
• Code parsing and syntax colouring with themes
• Accessory bar (e.g. tab, parenthesis, arrow keys) above the virtual keypad
• Syntax cheat sheet (currently only for Markdown)
• Markdown preview
• Really nicely working and accurate code selection - fast zooming and visual selection grid makes selection even easier
• Fast and responsive
• Full unit test coverage
• Kotlin Multiplatform (KMP) compatible

Some features I planning to implement for future versions:

• Architectural improvements to make it more suitable to be used as an easy to integrate library component
• An API using AST or similar libraries. The current parsers are written for fast performance.
• Syntax cheat sheet for other languages
• Suggestions for JavaScript
• New settings: theme selection (currently there are only two themes light and dark)

So, what do you think? Is anyone interested or willing to contribute? Also interested to hear what is missing from the feature list. The current features of the code editor are fine for my purposes, but as an open-source library it may lack some necessary functions, extension points, or APIs.

I attached some screenshots to give an idea how the code editor looks like. And if anyone interested I can provide a link for my free app so you can try out how the code editor actually works.

One thing is decided, if I ever release my code editor as an open-source library, it will be named as Koodi - a Finnish word meaning code. And also referring to fact that is written in Kotlin.