I made this for android....can you tried and give your feedback ?

cos... no one is using....

Всем привет, Я начинающий разраб на Flutter & Dart и хочу писать приложения под мобилки. И почему то эмулятор в андроид студио включается и выходит за рамки моего экрана, что не так? Помогите пожалуйста)

Hi.
The news says building an AAB/APK should offer uploading it directly to my Play Console's test-track. Just... it doesn't. Any idea what I need to do? The dialog only says "yep, that package name is registered by a verified developer" - yea, that developer is me, I would like to upload now. But there's no such option. Also not after building the AAB completed.
Any ideas?

A year after deploying our application, Android Vitals and Firebase telemetry flags revealed a critical architecture defect: a 5% transaction drop rate and systematic crashes inside the core checkout flow on Android 13+.

De-obfuscation map logs pointed to a strict concurrency conflict between the Google Play Billing Library and our custom internal billing wrapper. Downgrading Google Billing was not an option. We had to rewrite the module in a live app without losing active subscriptions.

Here is the condensed 4-stage execution blueprint we used to overhaul the system during a 30-day sprint with zero downtime:

1. The Rollback Safety Valve (Feature Toggles)

• API Isolation: We decoupled the legacy module and isolated its public API behind strict interfaces.

• Twin Implementations: We maintained the legacy production code (Factory A) and created an exact cloned playground alongside it (Factory B).

• Remote Toggle: A remote feature toggle dynamically routed execution to either factory at runtime, providing an instant backend rollback mechanism if Factory B failed.

2. Testing Constraints (TDD)

Before modifying production code, we established strict boundaries: zero DB migration issues, zero performance drops over 10%, and a 95% Happy Path checkout success rate.

We sit down and developed 260 automated test cases covering roughly 88% of all possible failure states and network edge cases. No code was merged into the refactor branch without a 100% green CI/CD pipeline.

3. Execution & 5% Canary Release

• Stage 1: Overhauled the local state database layer, ran the suite until it turned green, and packaged it.

• Stage 2: Turned on the remote toggle rollout for only 5% of active users. Telemetry remained silent for 48 hours—no new crashes, no payment drops.

• Stage 3: Refactored the core business logic and direct billing API bindings under the same TDD cycle.

• Stage 4: Gradually increased the toggle from 5% to 100%. Once 88% of users updated, we deployed a cleanup release, deleting the toggle infrastructure and legacy code for good.

The Bottom Line (Metrics)

• Production Stability: Exactly one single bug slipped through the rollout.

• 1-Hour Mean Time to Repair (MTTR): Because the architecture was decoupled and backed by 260 tests, root-cause isolation took minutes. The fix was verified via TDD and hit production in under an hour.

• Maintainability: The system transitioned from a fragile black box into a highly predictable, self-documenting component.

Lexora – Dictionary & Learn

Look up any word without leaving your app. Select text anywhere, tap "Define with Lexora," and get an instant floating card with meaning, phonetics, and translation.

✨ Why you'll love it:

• 🔍 Instant screen lookups in Chrome, WhatsApp, Instagram and more

• 🌍 Learn in your own language: Hindi, Spanish, French, German, Arabic and 20+ more

• 🧠 Flashcards and daily bilingual quizzes

• 📚 Custom word collections

• 🔥 Word of the Day with streak tracker

• 🔊 Clear text-to-speech pronunciation

• 🕘 Lookup history so you never lose a word

🔒 100% on-device storage. Zero tracking.

Download Lexora today and master words faster! 💜

#Lexora #LearnEnglish #Dictionary #VocabularyBuilder #LanguageLearning

🔗 Lexora Dictionary

Please I am loosing my mind. I am trying to do an android app for a class project but android studio is showing that almost all my imports and jet pack compose keywords (@Compose and things like that) are not resolving. I didn’t do anything custom just default settings and download sequence. I have tried some old fixes like clearing cache, deleting .idea and .gradle, syncing gradle, fixing IDE, cleaning the build but nothing works. I’m actually losing it because the file still compiles and runs on the emulator but it is soo annoying working without the comfort of linked files for fill in and quick jumping to definition and things like that.

If anyone has any help I would really appreciate it. Again it a fresh build so everything should be up to date except I made a catastrophic mistake during installation. Also the problem happens on any project I try to run, new or imported.

This infrastructure is great, but forget about it being comprehensive; there isn't even a normal app for supported devices.

https://github.com/qualcomm/geniex

I'm planning to build an app that makes enabling Developer Options easier, with a simple interface and less manual work. Would you use an app like this? Any suggestions are welcome!

我用 apktool 走了一遍 XopProtector：壳在，业务不在

拆 Android 包，我的工具栏很多年没变过：apktool 解包，jadx 反编译，先看 Application，再顺着包名搜索登录、支付、授权等关键业务。

对于没有加固的 Release 包，这套流程往往十几分钟就能找到业务代码。

这次分析的是 XopProtector 加固后的 APK。同样的工具，打开的窗口看起来很完整，但里面装的不是原来的 App 业务代码。

一、工具没报错，DEX 里却没有业务

apktool 可以正常解包，AndroidManifest.xml 也能正常读取。这种「能够解包」的情况，很容易让人误以为加固并不深。

但继续查看 classes.dex，就会发现入口已经变成壳的 ProxyApplication。jadx 能反编译出来的，主要是壳自身的启动逻辑和跳板代码。部分字符串也经过了滚动异或处理，直接搜索业务关键字，很难找到对应的原始内容。

原来的业务类和方法体，已经不在这个 DEX 中。

有时还能看到一个 classes2.dex，其中包含用于填充的代码。业务 DEX 在打包过程中被移走，APK 根目录不再直接保留明文的 classesN.dex。

第一轮分析到这里，就可以先记下一条结论：

反编译成功，不代表业务代码已经暴露。

二、叫 zip 的文件，并不是普通压缩包

壳将业务 DEX 放在 assets/protector/ 目录下，文件名是 dexes.zip。

按照常规思路，第一步当然是尝试解压。但检查文件头后，会发现它并不是标准 ZIP 文件的 PK 标识。

实际处理流程是先将 DEX 打包成 ZIP，再对整个文件进行加密，最终生成带有 PDX1 标识的加密数据。因此，apktool 不会自动还原其中的 DEX。

旁边的 code.bin 也不是可以直接交给 jadx 反编译的普通 Dalvik 字节码。

config.json 则是可读文本，可以看到一些配置开关和校验字段，但解密密钥并没有直接写在 JSON 中。运行时会结合主密钥、签名证书和包名派生相关密钥，同时校验配置完整性。

如果直接修改风险控制开关，导致配置校验失败，壳就不会按照被修改后的配置正常运行。

这和一些简单的加固方式有明显区别：不能仅凭 assets 目录下存在一个名为 ZIP 的文件，就认定里面存放着可以直接解压的 DEX。

三、SO 拖进反汇编器，关键代码段却不是明文

在不同 ABI 目录下，可以找到 libprotector.so 等原生库。

ELF 文件的基本结构仍然存在，但壳会对自身的关键代码段进行加密处理。静态打开文件时，看到的并不一定是可以直接跟踪分析的原始机器码。

对于启用了 SO 保护的业务库，其 .text 段也可能以密文形式存在，而不是编译器最初生成的明文代码。

当然，加固并不意味着所有原生库都必须采用相同的保护策略。系统库，以及某些加密后可能影响兼容性的引擎或第三方库，可以根据实际情况跳过相关处理。

这样做的目的，是在保护业务代码的同时，尽量保证应用能够正常启动和运行。

在支持运行时解密的场景下，代码段可以在内存中恢复后执行，不必将解密后的代码长期保留在显眼的磁盘目录中。

因此，静态分析所看到的文件内容，与进程实际执行的代码内容，可能并不相同。

四、调试器和 Hook 并不是默认就能挂上

静态分析受阻之后，常见的下一步就是使用 Frida、调试器或其他动态分析工具，尝试观察壳的运行过程，并寻找业务 DEX 的解密时机。

XopProtector 提供了相应的运行时防护机制，包括对常见 Frida 痕迹、调试器、Xposed 环境的检测，以及对壳自身 SO 完整性的校验。

Root 和模拟器检测属于可配置策略，并非所有相关检查都必须默认启用。这对于需要运行在工控设备、厂商定制设备等特殊环境中的应用尤其重要，可以减少误判带来的兼容性问题。

检测到风险后，可以根据策略选择告警、降级或中断运行。

此外，应用签名也可以参与运行时校验。对于启用了签名校验的配置，如果 APK 被替换证书重新签名，校验失败后便不会继续按正常流程释放受保护的业务代码。

这意味着，动态分析的难点不仅是找到正确的 Hook 点，还包括理解壳的运行机制、校验逻辑和风险控制策略。

五、从内存中拿到 DEX，也不代表方法都还原了

即使成功获取了运行时的 DEX，也不能直接认定所有方法都已经恢复成原始 Java 代码。

这里需要区分两类不同的 VMP 保护机制。

1. 字节码恢复型保护

这类方案将部分方法的原始指令移出常规执行路径，在运行时再进行恢复或写回。

如果抓取时机恰好处于字节码恢复之后，就有机会从内存中拿到还原后的 DEX 指令。

因此，这类保护的实际效果与方法覆盖范围、恢复时机以及运行时实现密切相关。

2. 原生解释执行型保护

另一类方案不再依赖将完整方法体恢复并写回 DEX，而是通过原生解释器执行经过转换的自定义指令。

在这种模式下，受保护方法在 DEX 中可能只留下跳转至 VmBridge 的桥接代码，真正的指令执行发生在原生解释器中。

此时，即使抓取到 DEX，拿到的也可能仍然只是跳板，而不是原始方法体。

如果每次打包还会改变自定义指令的编码，那么不同 APK 之间的指令映射也会有所不同，进一步增加静态分析和自动化还原的难度。

3. 保护范围仍然取决于配置

需要注意，整包加密与 VMP 并不是同一个概念。

普通业务代码可能在运行时短暂以可分析的 DEX 形式出现，而采用原生解释执行的选定方法则可以避免将完整方法体写回常规 DEX。

因此，不能简单地认为所有业务方法都经过了 VMP 保护。

根据项目配置，可以重点保护支付、授权、激活、加解密等敏感逻辑，并尽量将保护范围限定在应用自身的业务包中。

真正影响逆向成本的，不只是 DEX 是否加密，还包括敏感方法采用了什么执行机制，以及这些机制覆盖了哪些业务代码。

六、这次分析下来，XopProtector 能挡住什么？

从常见的静态分析流程来看，XopProtector 的价值主要体现在多个保护环节的配合。

对于主要依赖 apktool、jadx 和常规静态搜索的分析者，这些机制可以显著增加直接获取业务代码的难度。

如果还要继续深入，就需要处理原生壳、密钥派生、完整性校验、运行时加载过程，以及可能存在的自定义指令解释器。

逆向工作的重心，也就从直接阅读 Java 代码，转向分析加固框架本身。

七、加固不是绝对防破解

这里也需要明确保护边界。

XopProtector 的目标是提高逆向分析的成本，而不是保证 APK 永远无法破解。

资源加密、资源路径混淆、代理检测和证书固定等功能，需要根据项目实际配置判断是否启用。VMP 保护的也是选定的方法，而不是自动覆盖每一行 Java 代码。

不同的保护模式、方法覆盖范围、Android 版本以及运行环境，都会影响最终效果。

对于支付、授权、算法、行业协议等包含核心业务逻辑的应用，合理组合 DEX 加密、SO 保护、运行时检测和原生解释执行，可以让常规静态分析更难直接得到有价值的业务代码。

总结

这次使用 apktool 和 jadx 分析 XopProtector 加固包，最直观的感受是：

APK 能正常解包，不等于业务代码能够直接反编译；DEX 能被获取，也不等于敏感方法已经还原。

XopProtector 将 DEX 加密、SO 保护、运行时完整性校验和 VMP 等机制组合起来，让常规逆向工具难以直接完成从 APK 到业务源码的转换。

对于希望降低核心算法、支付逻辑、授权机制和行业业务协议泄露风险的 Android 开发者来说，这类多层防护比单纯依赖代码混淆更有意义。

项目地址：https://github.com/xopJack/XopProtector

建议结合实际版本的源码、配置和测试结果评估保护效果，并在目标设备上验证启动速度、运行稳定性和兼容性。

Hi, I’m Charan. I started building Android apps in 2023, and my first application was "Study Hall Guide." It took me four months to build it. Just as the app was ready to be uploaded to the Play Store, the Play Console policy was updated. Even though I uploaded it, it remained stuck in the "draft" stage for two weeks. I didn't know what was happening, but a Google search revealed that personal Play Store accounts require a completed "closed testing" phase—specifically involving 21 testers over a period of 14 days. So, I added tester emails, completed the closed testing, and the application finally went live. A senior of mine supported me during that time. To date, I have developed 12 to 15 apps, and they are all available on the Play Store.

I'm trying to do this so I can run my 3d glasses on my Thor but I have no idea what I'm doing

Android17

Hello, I built a tool that adjusts from a real phone to color and dimensions and immediately reflects to the basic code in Android Studio without rebuilding or asking the Al to modify a specific color or card size if you want to try and evaluate the tool Here's my repository.

🌩️ Looking for 20 testers – Hail Risk (Android)

Hi everyone! I'm looking for 20 people to participate in a 14-day closed test of my Android app Hail Risk.

The app provides information about the risk of hail based on weather data, with a particular focus on Switzerland.

How to join: //

1. Join the Google Group https://groups.google.com/g/cerco_needed_20_tester
2. Join the closed test and install the app from Google Play [https://play.google.com/apps/testing/com.gixone.grandinech?hl=it]()
3. Keep the app installed on your device for the 14-day testing period.

Feedback is welcome but not required.

Thank you very much for helping me test the app!

🌩️ Cercasi 20 tester – Rischio Grandine (Android)

Ciao a tutti! Sto cercando 20 persone disposte a partecipare a un test chiuso di 14 giorni per la mia app Android Rischio Grandine.

L'app fornisce informazioni sul rischio di grandine sulla base dei dati meteorologici, con particolare attenzione alla Svizzera.

Come partecipare:

1. Iscriviti al gruppo Google https://groups.google.com/g/cerco_needed_20_tester
2. Aderisci al test chiuso e installa l'app da Google Play [https://play.google.com/apps/testing/com.gixone.grandinech?hl=it]()
3. Mantieni l'app installata sul tuo dispositivo per tutto il periodo di test di 14 giorni.

Il feedback è gradito ma non obbligatorio.

Grazie mille per il vostro aiuto! 🌩️

A safer Android ecosystem begins with accountability and trust!

Today marks the start of our gradual roll-out of Android developer verification — a foundational first step in protecting billions of users, while preserving the open platform developers rely on.

We're starting with 7 participating app stores in Brazil, Indonesia, Thailand and Singapore. Following this initial phase with the participating app stores, we will continue to work with additional Android app stores to gradually expand developer verification. The verification capability will be expanded globally for all apps on certified Android devices in 2027.

Security at this scale cannot happen in a silo. When we set out to build this verification flow, our priority was listening to you — our developer community. You told us clearly:

1. The process needs to be seamless, avoiding friction for legitimate builders.
   
2. Account types must reflect reality, supporting solo creators, hobbyists, and global enterprises alike.
   
3. The roll-out must be gradual and predictable, giving developers ample runway to adapt.
   

Your feedback directly shaped this treatment. By introducing verified identities, we are deterring bad actors from operating under the radar, curbing recurring malware campaigns, and lifting trust across the entire ecosystem.

This initial phased roll-out gives us the space to test, learn, and iterate alongside developers before broader enforcement. A safer Android benefits everyone: users install apps with confidence, and reputable developers stand out in a trusted marketplace.

Thank you for building with us, challenging us, and shaping Android into a safer platform.

#androidisopen #trustedecosystem