phh

Cheapest Spreadtrum (now Unisoc) you can buy is SC7731E, which has at the very least Android 7, and is slated to get Android 13 BSP.

Most current cheap rockchips are rk3328/rk3228, who got at least Android 8, even more recent (I think 3328 got Android 12). Last Allwinner board, H616, I got was running Android 9, but it was few years ago so it was pretty recent, and it's considered an obsolete SoC on several accounts. I don't really know what Amlogic sells nowadays

Granted, I only buy devices for which the the Android devices is displayed, because well I want GSI to run on it, but I haven't seen a device sold as Android 4.* for years. I ordered an iPhone knock-off that might prove me wrong... (it says Android 11 on the spec sheet)

Nice write-up. Still a lot to go through, I hope the author have the will to continue further (they already put a lot of courage in it.)

If I may, regarding the "BUND" magic. I'm sorry to disappoint, but it's likely just "fourcc" (as in, a stirng that fits in an int32) for "bundle".

Yes, that was both impressive and instructive.

What are the order of magnitude of price launch for a cubesat nowadays?Are there already commercial prices for moon cubesats?

What's the minimal equipment required (assuming just a simple communication sat)? Does it require attitude and vector control?

> I think it's not unreasonable to just declare those devices as insecure and move on.

1. The lockscreen bypass security flaw of last week is major compared to any flaw Qualcomm currently have.

2. Apple still updates devices hit with checkm8, so maybe security doesn't dictate everything for them. Not sure why it needs to for Google.

3. What does security has to do with getting Material You to my device? (to give just one example). Maybe the idea is that if a device is insecure, then it must get to the trash bin...? I hope not.

I run latest Android version on my 6 years old Pixel 1. The only reason it isn't provided by Google is that Google doesn't want to.

Using xkb map us(intl-unicode) it's a then alt gr + shift + " (I'm not totally sure if that's the correct, and ß is alt-gr + s.

Your comment is already pretty great :-) I used to ask donations, thinking every donation no matter the size would warm my heart, but it doesn't really work (unless it's big enough for me to buy new smartphones for debugging). I do take donations at https://github.com/sponsors/phhusson

What makes me happier is seeing people using my work, either users' feedback telling me why my work is useful for them, or developers creating new things based on my work (the weirder the usage the better)

I'm happy to see some interest in custom ROM. I personally think that nowadays this is the best way for a software engineer to have a meaningful impact on their own daily life.

If your goal is just to peak behind the curtain and see how those things gets built other comments will probably be more relevant than mine.

You'll need a pretty beefy Linux machine 200GB SSD storage, 32GB RAM, >8 CPU cores is recommended. You can go lower, but it becomes painful for development. ROM developers with less resources than that build on VPS.

If you want to start developing things Android-side (which means not the hardware/driver parts), I recommend:

- Use GSIs (Generic System Image) -- often on custom rom, it's a pain to build device-specific ROMs because you're always missing parts, and dependent on just the one developer maintaining that device. GSIs are more likely to be less painful to work with

- You can launch Android Studio inside AOSP using aidegen (I don't remember the exact syntax). For development on app-side (like if you want to change the UI) this will help a lot (but eat even more RAM)

- Android build system is very robust when it comes to incremental build, you should never have to clean anything. Maybe in some cases you might need `make installclean`, but except in horrible cases, that's all.

- You can build and replace specific components. For instance, if you just want to do quick cycle development on SystemUI, you can do `make SystemUI` to just build SystemUI, and replace it on your device with `adb root; adb remount; adb push out/target/product/xxxx/system/priv-app/SystemUI/SystemUI.apk /system/priv-app/SystemUI/SystemUI.apk` and soft-reboot android with `adb shell 'stop;start'`. Some components are APKs that can simply be installed, in which case you don't even need to soft-reboot android, and adb install -r out/target/product/xxxx/system/priv-app/Settings/Settings.apk` will do the trick

If you start developing "long term", consider that AOSP changes A LOT from one version to another, and Google has really no remorse to break stuff inside AOSP (not blaming, just stating), so always consider making apps rather than changing things inside Android framework. (Android has a notion of "system" and "privileged" apps, that can do a lot more than standard apps. The API you need to use in that case is not guaranteed, but it's less likely to move). If you can't make things into apps, then implement your feature with the lowest possible entry points coming from AOSP.

Once you got your first builds up and running, started trying to develop changes and know what change you want to do, feel free to ping me for pointers: phh on libera or @phhusson on telegram

FWIW, if it's of any use, a "oneliner" to build my AOSP GSI (so a "pure" AOSP, that will work on 95%+ of Android devices that are less than 4 years old): mkdir build; cd build; repo init -u https://android.googlesource.com/platform/manifest -b android-12.1.0_r14 ; git clone https://github.com/phhusson/treble_manifest -b android-12.0 .repo/local_manifests; repo sync -j12; (cd device/phh/treble;bash generate.sh);. build/envsetup.sh ; lunch treble_arm64_bvS-userdebug; make -j128

And image appears in out/target/product/phhgsi_arm64_ab/system.img

If you use any always-listening (see rooting exploits over wifi beacons) general purpose computer for high risk applications, it's a bit your fault.

> You’re telling me that android keeps keys in memory for its entire uptime?

Yes. I've known that for quite some time, and yet I keep forgetting considering how stupid this feels [1] . Google provides "lockdown" button which is supposedly more secure (I think it's recommended for journalists?)... Well it doesn't evict keys either. Only eviction is to reboot.

[1] It feels stupid because there had been a LOT of work to move from FDE to FBE and to allow two states of data encryption and telling apps to support both of them. Doing all this work just to be able to store incoming SMS and to display wallpaper on first lockscreen...?

It's super weird not to provide a GSI, it's pretty easy to do, and would allow you to reach hundreds of phone models with just one build.

Are you pursuing this way but are hitting issues with it?

My dream UX for that is a single ambient led ranging from green to red, but making it overall usable counting we're two, using two different trains, with different WFH schedule is rather complicated

S10e definitely has a hw proximity sensor under the screen, but Samsung also adds infos from touchscreen to complement this sensor. I used a s10e and loved it, but not on Samsung sw and I never did calls so I can't say much about it.

I'm making the argument that consumers pay for ads, because if the company didn't make any ads, it'd cost them less so they could decrease the price of the product?

> without paying with our credit cards

I'm not sure whether your message is an advocacy for 0 click micro-payment, or whether it's assuming that consumers don't pay for the ads.

Yup, that's called Goodhart law

Not sure why you'd say "not even Verizon". Verizon is literally the worst carrier worldwide (ok maybe after NTT) with regards to interoperability.

1. True RCS isn't supposed to go through internet, it's supposed to go through same way as SMS and voice calls (which is also a data connection, but specific to sms/rcs/voice)

2. That's not a requirement even though Google does their best to kill all alternative implementations. (Samsung had one, but Google paid them a lot of money to get rid of it. I have to admit I don't know who is left with their own RCS client)

> So, RCS is not a replacement for SMS.

It's 100% a replacement to SMS, it's literally defined in the same spec as SMS over LTE, as an upgrade to SMS. Though yeah Google made it, this... uh... thing. RCS is technically a federated standard, but Google killed every part of the federation and some parts of the standard.

Yes, TCP/ip and SIP, no magic packet, but: 1. You need to do challenges with the SIM card for authentication 2. On most carriers, "ims" is on a special IPv6 data connection that can't be used by apps.

The specifications are public, but yeah it requires a lot of work to get into.

That being said, I think neither of those limitations apply to Google's "RCS" (which bypasses carriers, so they can't get their own IPv6 connection and I don't think they can use SIM challenges for auth), so I think it should be possible in a 3rd party app.

Even though the subject is real, and has good reasons that it might not be fixable, the article feels very loosely based:

The whole experience is based on a precise bespoke VR app. There is no information about it, or the used headset. To be fair that info might be available in the paper, but that's still bespoke app we can't know the quality of.

This quote makes me doubt even more:

> “If my iPhone doesn’t load a page instantly, I might grumble about it, but that’s the end of it,” Ringgenberg told The Daily Beast. “If my VR app stutters on me, I might physically get sick. That does keep people away from this technology.”

This is perfectly true! When it happens on my oculus quest 2, I immediately feel dizzy. BUT I can count the number of times it happened to me over a hundred hours of play on my fingers. (Notably I can reproduce one IO related freeze in Synthriderz' Lindsey Stirling Experience)

Also, this article doesn't mention brain rewiring: if we hand over modern smartphones to the average 2002 computer person, they would have no idea how to use it "where's the cursor", " how do I move windows", "why is my screen getting junk on its top without my will", " why isn't there a button to switch programs"? We just upgraded our brains to handle that. Same could happen with VR.

I'm definitely not a metaverse advocate, I still fail to see it immersive enough and cheap enough to work, and it requires a huge shift back to actually giving attention (which is ironic considering Facebook killed that attention). But I think the Oculus Quest 2 is an excellent game console (which implies it is not for everyone and that's fine)

Android has Speedify app that can do that (proprietary app and back end, with no self hosting)

GPDR is about private data, how does a static affiliate link breaches private data?

2011 Motorola Atrix https://arstechnica.com/gadgets/2011/03/motorola-atrix-the-u...

Well French dvb standard is requiring e-ac3, so not all standardizers got the memo... (And it's being used mostly in stereo)

Fwiw, Dolby does bring something compared to PCM, which is metadata to dynamically change dynamic range on the final device, allowing higher ranges with perfect home cinema and smaller range when in a noisy environment

That being said, I hope we plan on no longer depending on Qatar either, because their stability doesn't seem a given either.

Also, GPDR's origin dates back to French CNIL, which goal was to reduce government's power on private data.

Yup. That's the reason I kept 2011-2021 without ad blockers. But yeah I could no longer live in that hell.

Fwiw ads have more properties than just being micro payments. Another property is that the price is a monotonic growing function of your revenues, so """every viewer contribute with how much they can"""

Who came first? The AGI or the human?

Right, like no megacorp ever prevented us from doing whatever we want for our smartphones. Oh wait. (No Pixels don't count, unless you can write your own TEE, your own sensor hub, and your own wake up word)