Android Development

GitHub repository: https://github.com/GetStream/photoview-android

Full text: "On February 15th I will be speaking at the committee of petitions of the European Parliament to discuss software attestation on devices running Android through Google Play Protect and SafetyNet and how it affects competitors, here's the link if you want to follow it live."

Today, we are introducing a new tool that will prompt these users to update, bringing them closer to the app experience you intended to deliver.

Play recovery tools allow you to prompt users running specific versions of your app to update every time they restart the app.

cross-posted from: https://programming.dev/post/9220472

I've just had this happen (and then stop again) for the second time in a few weeks. This is a new MAUI app where the only thing I've changed so far, other than add a few of my own (already previously tested and working) libraries, is change the home page, and the new home page only has a couple of labels on it, so it has no complexity at all added to it yet, and yet getting this odd alleged memory issue. The first time it happened I couldn't find a fix for it, left it for a while, came back (a week's worth of reboots later) and it was working again. Then today I made one trivial change - added a debug write - and the problem came back (but got past the new line without any issues). Then I rebooted and it's working again.

I have 32Gb of RAM, with 12Gb allocated to a RAMdisk, and I have my paging files set to use the RAMdisk.

It generated a log file which said...

"Native memory allocation (mmap) failed to map 186646528 bytes for G1 virtual space"

...so it only needed 180Mb, and down near the bottom it says...

"Memory: 4k page, system-wide physical 32579M (3638M free)"

...so I had more than enough space left (so the memory message may be a red herring for whatever did cause the crash). Googling that first message brings up a bunch of matches, but none of which are for MAUI Android (all different cases with different fixes).

This is using the Android emulator on a Windows machine where I've set the paging sizes to be system-managed. I'm not sure where the Android emulator actually gets memory from though - the system RAM? The paging RAM(disk)? The build directory? The user's App directory?

It reminds me of years ago there was a similar issue with Xamarin Android where the fix/workaround was to add a line to the csproj (I think it increased the heap or something from memory), but I haven't seen that pop up in a long time. Not sure if this is the same issue or a different one.

There's no repro for it cos I can't even reliably repro it. I'm just concerned that it's going to keep coming back given I haven't even added any complexity to it yet.

Has anyone run into this and/or knows how to fix it?

cross-posted from: https://programming.dev/post/7754605

For details see VS 17.8.3 Android emulator API 28 deployment fails "Emulator is not ready to be used" and please upvote the issue

How to do it on a high level? Given that I know what to modify in the code.

Also, I won't want to rebuild the parts of the kernel that aren't necessary. The Wifi driver should be rebuild in isolation, that is.

Orange group keeps alive and available an interesting and very rich web site providing plenty of rules and advices about accessibility. The content targets iOS, Android, web and also other mediums.

To help developers reap these benefits, developers with newly created personal Play Console accounts will soon be required to test their apps with at least 20 people for a minimum of two weeks before applying for access to production. This will allow developers to test their app, identify issues, get feedback, and ensure that everything is ready before they launch. Developers who create new personal developer accounts will start seeing this requirement in Play Console in the coming days.

Juste wanted to share this old story about my first Android app, some mistakes I made and the Google banishment 😅

Google today announced two changes to AdSense but doesn’t “expect publishers to see a change in their earnings” and payments. Consistency and “greater transparency” were cited as the reason for these updates.