Rant: Google Play's warning that users can't download certain apps because they're "made for an older version of Android" has issues.
While this is done to ensure that users only install apps that abide by the latest privacy & security features of Android, it has some unintended consequences.
First of all, a bit of context. Back in April 2022, Google announced that it would expand Play's target API level requirements to "strengthen user security". Google said that "existing apps that don’t target an API level within two years of the latest major Android release version will not be available for discovery or installation for new users with devices running Android OS versions higher than apps’ target API level."
(Target API level determines what app-facing system behaviors the app is affected by. An app that targets API level 33 is affected by system behaviors of Android 13.)
* Since November 1, 2022 (or May 1, 2023 if the developer requested an extension), an app that targets API level 29 (Android 10) or lower can't be discovered or installed by new users with devices running an Android OS version higher than the app's target API level.
* Starting August 31, 2023 (or November 1, 2023 if the developer requests an extension), this will extend to apps targeting API level 30 (Android 11).
While in many ways this makes things more secure overall for users, as apps targeting older API levels aren't subject to a lot of the privacy & security restrictions introduced by newer Android versions, simply telling many users on Google Play they can't install an app isn't going to stop them from trying.
In fact, as pointed out by @phhusson, it may even lead to an increase of users downloading potentially dangerous versions of apps from sketchy websites. If you Google the error message, for example, you'll find threads on Reddit and elsewhere suggesting you to sideload the app. Google's generative AI response even recommends you sideload the app!
(1/2)
While this is done to ensure that users only install apps that abide by the latest privacy & security features of Android, it has some unintended consequences.
First of all, a bit of context. Back in April 2022, Google announced that it would expand Play's target API level requirements to "strengthen user security". Google said that "existing apps that don’t target an API level within two years of the latest major Android release version will not be available for discovery or installation for new users with devices running Android OS versions higher than apps’ target API level."
(Target API level determines what app-facing system behaviors the app is affected by. An app that targets API level 33 is affected by system behaviors of Android 13.)
* Since November 1, 2022 (or May 1, 2023 if the developer requested an extension), an app that targets API level 29 (Android 10) or lower can't be discovered or installed by new users with devices running an Android OS version higher than the app's target API level.
* Starting August 31, 2023 (or November 1, 2023 if the developer requests an extension), this will extend to apps targeting API level 30 (Android 11).
While in many ways this makes things more secure overall for users, as apps targeting older API levels aren't subject to a lot of the privacy & security restrictions introduced by newer Android versions, simply telling many users on Google Play they can't install an app isn't going to stop them from trying.
In fact, as pointed out by @phhusson, it may even lead to an increase of users downloading potentially dangerous versions of apps from sketchy websites. If you Google the error message, for example, you'll find threads on Reddit and elsewhere suggesting you to sideload the app. Google's generative AI response even recommends you sideload the app!
(1/2)
👍49❤2🤔2
Mishaal's Android News Feed
Rant: Google Play's warning that users can't download certain apps because they're "made for an older version of Android" has issues. While this is done to ensure that users only install apps that abide by the latest privacy & security features of Android…
So this makes me think: Why not just add an "install anyway" button on Google Play (after the user acknowledges the warning)? If the app is malicious or harmful, it should just be removed. Otherwise, just inform the user about potential issues and let them make their choice.
This is not a wild suggestion. Android itself already warns users when they try to run an app that targets older API levels. (The threshold for this warning to appear was bumped from API level 23 in Android 13 to API level 28 in Android 14.)
Android 14 also has an additional protection layer in the form of the minimum installable target API level. The OS won't let you install apps that target an API level older than 23, which is when runtime permissions were introduced.
Obviously, most users won't be running Android 14+ for a while, so Google Play's target API level changes protects older users in the interim. But still, if the app is on Google Play, it should be downloadable. If it's malicious, then remove it. If it's simply outdated and thus not using the latest security features, just warn users. Maybe make it so discoverability limitations apply to apps targeting API levels < 30, pre-install warning dialogs appear for apps targeting API levels < 28, and hard installation limitations only apply to apps targeting API levels < 23, matching Android 14's behavior.
"Well, these developers should just update their apps!" A lot of indie app and game developers barely make money from their projects or just do it out of passion. They may not make a lot of money for Google Play, but they should simply not be rewarded (through favored discoverability/search rankings) for not updating their apps rather than punished. Lots of games and useful apps (like the "My Sensors" one, which a LineageOS developer tried to install for testing something) don't need yearly updates.
(2/2)
This is not a wild suggestion. Android itself already warns users when they try to run an app that targets older API levels. (The threshold for this warning to appear was bumped from API level 23 in Android 13 to API level 28 in Android 14.)
Android 14 also has an additional protection layer in the form of the minimum installable target API level. The OS won't let you install apps that target an API level older than 23, which is when runtime permissions were introduced.
Obviously, most users won't be running Android 14+ for a while, so Google Play's target API level changes protects older users in the interim. But still, if the app is on Google Play, it should be downloadable. If it's malicious, then remove it. If it's simply outdated and thus not using the latest security features, just warn users. Maybe make it so discoverability limitations apply to apps targeting API levels < 30, pre-install warning dialogs appear for apps targeting API levels < 28, and hard installation limitations only apply to apps targeting API levels < 23, matching Android 14's behavior.
"Well, these developers should just update their apps!" A lot of indie app and game developers barely make money from their projects or just do it out of passion. They may not make a lot of money for Google Play, but they should simply not be rewarded (through favored discoverability/search rankings) for not updating their apps rather than punished. Lots of games and useful apps (like the "My Sensors" one, which a LineageOS developer tried to install for testing something) don't need yearly updates.
(2/2)
👍49❤6💯5🔥2👏2
How to make your Android widget display on the cover screen of the Samsung Galaxy Z Flip 5
A recent blog post by developer Akexorcist shows how to make your app's widget appear on the outer display of the Galaxy Z Flip 5.
The Galaxy Z Flip 5 has a 728x720 resolution outer display measuring 3.4" diagonally, which is much larger than on last year's model. However, by default, only select app widgets can appear on the cover screen.
Samsung, for whatever reason, hasn't published official documentation yet on how to do this, so Akexorcist said they had to decompile the Good Lock app to find out how this works.
You can read their blog post here.
(If you're a user, you can either use the MultiStar module [part of the Good Lock suite] or the third-party CoverScreen OS app to force unsupported app widgets to appear on the cover screen.)
A recent blog post by developer Akexorcist shows how to make your app's widget appear on the outer display of the Galaxy Z Flip 5.
The Galaxy Z Flip 5 has a 728x720 resolution outer display measuring 3.4" diagonally, which is much larger than on last year's model. However, by default, only select app widgets can appear on the cover screen.
Samsung, for whatever reason, hasn't published official documentation yet on how to do this, so Akexorcist said they had to decompile the Good Lock app to find out how this works.
You can read their blog post here.
(If you're a user, you can either use the MultiStar module [part of the Good Lock suite] or the third-party CoverScreen OS app to force unsupported app widgets to appear on the cover screen.)
👍25🔥5🤡3
What will the upcoming "Watch Unlock" feature do and how is it different from Smart Lock > Trusted devices?
I still see a lot of confusion about Watch Unlock, which is set to come to the Pixel Watch, Galaxy Watch 6 series, and other devices, so here's what you need to know.
For a bit of context, Android supports a few authentication methods.
Primary authentication methods include PIN, pattern, or password. Primary authentication can be used to unlock the device or authenticate within apps.
Biometric authentication methods include fingerprint, face, and iris. Biometric authentication methods are classified into three tiers: Class 3 (formerly Strong), Class 2 (formerly Weak), or Class 1 (formerly Convenience). While all 3 can be used to unlock the device, only Class 3 and Class 2 biometrics can integrate with BiometricPrompt (ie. authenticate within apps). No matter what, though, you'll eventually have to fall back to primary authentication to unlock the device (72 hours if you've been using a Class 3 biometric, 24 hours for Class 2 or Class 1).
Finally, there are Trust Agents. Trust Agents cannot unlock the device. They can only extend the unlock duration for a device that is already unlocked. In other words, they just keep your device unlocked for longer.
You may already be familiar with "Smart Lock". It's been around for years as part of Google Play Services, and it's what's considered a Trust Agent. Smart Lock offered multiple ways to keep the device unlocked for longer: on-body detection, trusted places, trusted faces (before Android 10), and trusted devices.
Trusted devices is what many people are confusing with Watch Unlock. They are not the same. Trusted devices lets you pick a connected Bluetooth device (like your smartwatch) to extend the duration your phone is unlocked for. In other words, after you manually unlock your phone using either a primary or biometric authentication method, your connected smartwatch will keep your phone unlocked.
(1/2)
I still see a lot of confusion about Watch Unlock, which is set to come to the Pixel Watch, Galaxy Watch 6 series, and other devices, so here's what you need to know.
For a bit of context, Android supports a few authentication methods.
Primary authentication methods include PIN, pattern, or password. Primary authentication can be used to unlock the device or authenticate within apps.
Biometric authentication methods include fingerprint, face, and iris. Biometric authentication methods are classified into three tiers: Class 3 (formerly Strong), Class 2 (formerly Weak), or Class 1 (formerly Convenience). While all 3 can be used to unlock the device, only Class 3 and Class 2 biometrics can integrate with BiometricPrompt (ie. authenticate within apps). No matter what, though, you'll eventually have to fall back to primary authentication to unlock the device (72 hours if you've been using a Class 3 biometric, 24 hours for Class 2 or Class 1).
Finally, there are Trust Agents. Trust Agents cannot unlock the device. They can only extend the unlock duration for a device that is already unlocked. In other words, they just keep your device unlocked for longer.
You may already be familiar with "Smart Lock". It's been around for years as part of Google Play Services, and it's what's considered a Trust Agent. Smart Lock offered multiple ways to keep the device unlocked for longer: on-body detection, trusted places, trusted faces (before Android 10), and trusted devices.
Trusted devices is what many people are confusing with Watch Unlock. They are not the same. Trusted devices lets you pick a connected Bluetooth device (like your smartwatch) to extend the duration your phone is unlocked for. In other words, after you manually unlock your phone using either a primary or biometric authentication method, your connected smartwatch will keep your phone unlocked.
(1/2)
👍27❤2🙏1
Watch Unlock is different, as it can actually unlock your phone for you. Your watch just needs to be itself unlocked and on your wrist. While this is less secure than your primary or any biometric authentication method, it's far better than "Trusted Devices" which only checked if your watch and phone are connected at all. Google is pitching Watch Unlock as "another convenient way to unlock" your phone when "your fingers are wet or face isn't recognized".
Watch Unlock uses Android 13's new Active Unlock API and is basically treated like a new form of biometric authentication. In fact, Google is even testing integrating Watch Unlock under Android's biometric unlock settings in Android 14, as shown above.
(Note: The intro should have an additional line that says "You can unlock with your watch when your face or fingerprint isn’t recognized." but I don't know why it doesn't appear as my device meets the criteria.)
Watch Unlock hasn't rolled out officially yet, but it was mentioned by Google at CES 2023 earlier this year. Earlier this month, I discovered evidence suggesting the feature will be available on more than just the Pixel Watch (1 & 2), but this also has yet to be confirmed. I'll of course share an update as I learn more about this feature.
By the way, Google seems to recognize that people are going to be confused by this new feature, which is why they've begun the process of rolling out a rebrand/renaming of Smart Lock. They're changing it to "Extend Unlock" to better reflect what it actually does, as shown in the screenshot above.
(2/2)
Watch Unlock uses Android 13's new Active Unlock API and is basically treated like a new form of biometric authentication. In fact, Google is even testing integrating Watch Unlock under Android's biometric unlock settings in Android 14, as shown above.
(Note: The intro should have an additional line that says "You can unlock with your watch when your face or fingerprint isn’t recognized." but I don't know why it doesn't appear as my device meets the criteria.)
Watch Unlock hasn't rolled out officially yet, but it was mentioned by Google at CES 2023 earlier this year. Earlier this month, I discovered evidence suggesting the feature will be available on more than just the Pixel Watch (1 & 2), but this also has yet to be confirmed. I'll of course share an update as I learn more about this feature.
By the way, Google seems to recognize that people are going to be confused by this new feature, which is why they've begun the process of rolling out a rebrand/renaming of Smart Lock. They're changing it to "Extend Unlock" to better reflect what it actually does, as shown in the screenshot above.
(2/2)
👍28🤯3🤔2❤1
Software updates can sometimes take away functionality, which can be frustrating & discourage users from updating.
The Fairphone 3's Android 13 update, for example, took away the ability to use the fingerprint scanner for logging into many banking/password manager apps.
Why? Well, Fairphone had no choice. Google's compatibility requirements for Android 13 forced their hand.
Biometric authentication methods are classified into three tiers: Class 3, Class 2, or Class 1. While all 3 can be used to unlock the device, only Class 3 and Class 2 biometrics can integrate with BiometricPrompt (ie. authenticate within apps). That's why the Pixel 7's face unlock feature doesn't support verifying you within apps, as it's a Class 1 biometric. The Pixel 7's fingerprint scanner, however, is a Class 3 biometric, so it can.
Even though both Class 3 and Class 2 biometrics can be used for BiometricPrompt, though, apps ultimately decide whether they want to accept Class 2 or even Class 3 biometrics, using the setAllowedAuthenticators(...) method. Many apps with higher security requirements, like banking apps or password managers, accept Class 3 but not Class 2 biometrics, as the latter can't integrate with the keystore. I think you see where I'm going with this.
With its Android 13 update, the Fairphone 3's fingerprint scanner was downgraded from Class 3 to Class 2. The reason is because Android 13 strengthened the requirements needed for a biometric to be classified as Class 3, and the Fairphone 3's fingerprint scanner could no longer meet this requirement. To be clear, the Fairphone 3 was released in late 2019, so it's using older fingerprint hardware than most other devices running Android 13.
Highlighted in green above is the new requirement that biometrics have to meet to be classified as Class 3. This comes from the Android CDD for Android 13, which enumerates the requirements that devices have to meet in order to be certified as compatible with Android (and is a stepping stone to getting a GMS license).
(1/2)
The Fairphone 3's Android 13 update, for example, took away the ability to use the fingerprint scanner for logging into many banking/password manager apps.
Why? Well, Fairphone had no choice. Google's compatibility requirements for Android 13 forced their hand.
Biometric authentication methods are classified into three tiers: Class 3, Class 2, or Class 1. While all 3 can be used to unlock the device, only Class 3 and Class 2 biometrics can integrate with BiometricPrompt (ie. authenticate within apps). That's why the Pixel 7's face unlock feature doesn't support verifying you within apps, as it's a Class 1 biometric. The Pixel 7's fingerprint scanner, however, is a Class 3 biometric, so it can.
Even though both Class 3 and Class 2 biometrics can be used for BiometricPrompt, though, apps ultimately decide whether they want to accept Class 2 or even Class 3 biometrics, using the setAllowedAuthenticators(...) method. Many apps with higher security requirements, like banking apps or password managers, accept Class 3 but not Class 2 biometrics, as the latter can't integrate with the keystore. I think you see where I'm going with this.
With its Android 13 update, the Fairphone 3's fingerprint scanner was downgraded from Class 3 to Class 2. The reason is because Android 13 strengthened the requirements needed for a biometric to be classified as Class 3, and the Fairphone 3's fingerprint scanner could no longer meet this requirement. To be clear, the Fairphone 3 was released in late 2019, so it's using older fingerprint hardware than most other devices running Android 13.
Highlighted in green above is the new requirement that biometrics have to meet to be classified as Class 3. This comes from the Android CDD for Android 13, which enumerates the requirements that devices have to meet in order to be certified as compatible with Android (and is a stepping stone to getting a GMS license).
(1/2)
😢22👍11🤡6🤔3🙏1
Mishaal's Android News Feed
Software updates can sometimes take away functionality, which can be frustrating & discourage users from updating. The Fairphone 3's Android 13 update, for example, took away the ability to use the fingerprint scanner for logging into many banking/password…
Since the Fairphone 3's Android 13 build includes GMS, it has to abide by the CDD, so they had no choice but to downgrade the sensor to Class 2. Fairphone's initial rollout of the Android 13 update didn't mention this change, but they've since amended their update notification and release notes to warn users about this regression.
The Fairphone 4 isn't affected by this as it uses newer, more secure fingerprint hardware. Plus, the Fairphone 3's fingerprint scanner can still be used in a variety of apps. A post on the Fairphone forums maintains a list of which apps are affected. I've also seen Fairphone employees reach out to devs of affected apps to get them to update their UX so the change is less confusing to users, to their credit.
Final note: custom ROMs for the Fairphone 3 are largely unaffected by this change. That's because they can simply revert the change that downgrades the biometrics security classification from Class 3 to Class 2. Custom ROMs can get away with this because they don't care about passing Android certification requirements. This is a common practice when doing a bring-up of newer Android versions on older devices with outdated fingerprint hardware.
I'll have more information to share on this topic soon for Patreon/X subscribers!
(2/2)
The Fairphone 4 isn't affected by this as it uses newer, more secure fingerprint hardware. Plus, the Fairphone 3's fingerprint scanner can still be used in a variety of apps. A post on the Fairphone forums maintains a list of which apps are affected. I've also seen Fairphone employees reach out to devs of affected apps to get them to update their UX so the change is less confusing to users, to their credit.
Final note: custom ROMs for the Fairphone 3 are largely unaffected by this change. That's because they can simply revert the change that downgrades the biometrics security classification from Class 3 to Class 2. Custom ROMs can get away with this because they don't care about passing Android certification requirements. This is a common practice when doing a bring-up of newer Android versions on older devices with outdated fingerprint hardware.
I'll have more information to share on this topic soon for Patreon/X subscribers!
(2/2)
👍39🔥1
Modders have figured out how to make Pixel phones purchased outside of Japan compatible with the country's mobile payment system, Osaifu-Keitai.
By default, only Pixel phones bought in Japan are compatible with Osaifu-Keitai, but this is a software and not a hardware limitation. Shown above is a global Pixel 7 Pro (model ID GP4BC) purchased in Germany using Osaifu-Keitai in Japan.
For a bit of context, Osaifu-Keitai is the "de facto standard mobile payment system in Japan" as noted on Wikipedia. It's used for everything from electronic money to ID cards, loyalty cards, transit cards, and more.
Osaifu-Keitai uses Sony's FeliCa RFID smart card technology. FeliCa is the standard technology for Japanese smart cards, and it's also used in other APAC markets. To support FeliCa, phones either ship with a mobile FeliCa IC or a NFC chip that supports the NFC-F (JIS 6319-4) standard.
The Pixel 7, for example, ships STMicroelectronics' ST54K IC, a single-chip NFC controller and secure element. Pixels (as well as many other Android phones) use host card emulation (HCE) to essentially emulate a FeliCa RFID smart card that talks directly to the NFC reader.
This hardware is present on Pixel 7 phones globally, which means no matter where you buy the Pixel 7, it should be able to support Osaifu-Keitai. However, the Osaifu-Keitai app seems to implement multiple checks to see if FeliCa is supported on the device. One of those checks (on Pixel phones) ends up seeing if the device's SKU is found on an allowlist of Japanese-specific Pixel phone SKUs contained within the system "PixelNfc" app.
(Chart on NFC-F is from here.)
(1/2)
By default, only Pixel phones bought in Japan are compatible with Osaifu-Keitai, but this is a software and not a hardware limitation. Shown above is a global Pixel 7 Pro (model ID GP4BC) purchased in Germany using Osaifu-Keitai in Japan.
For a bit of context, Osaifu-Keitai is the "de facto standard mobile payment system in Japan" as noted on Wikipedia. It's used for everything from electronic money to ID cards, loyalty cards, transit cards, and more.
Osaifu-Keitai uses Sony's FeliCa RFID smart card technology. FeliCa is the standard technology for Japanese smart cards, and it's also used in other APAC markets. To support FeliCa, phones either ship with a mobile FeliCa IC or a NFC chip that supports the NFC-F (JIS 6319-4) standard.
The Pixel 7, for example, ships STMicroelectronics' ST54K IC, a single-chip NFC controller and secure element. Pixels (as well as many other Android phones) use host card emulation (HCE) to essentially emulate a FeliCa RFID smart card that talks directly to the NFC reader.
This hardware is present on Pixel 7 phones globally, which means no matter where you buy the Pixel 7, it should be able to support Osaifu-Keitai. However, the Osaifu-Keitai app seems to implement multiple checks to see if FeliCa is supported on the device. One of those checks (on Pixel phones) ends up seeing if the device's SKU is found on an allowlist of Japanese-specific Pixel phone SKUs contained within the system "PixelNfc" app.
(Chart on NFC-F is from here.)
(1/2)
🤯26👍12🔥1
Mishaal's Android News Feed
Modders have figured out how to make Pixel phones purchased outside of Japan compatible with the country's mobile payment system, Osaifu-Keitai. By default, only Pixel phones bought in Japan are compatible with Osaifu-Keitai, but this is a software and not…
If your device's SKU is on that list, then you're able to use Osaifu-Keitai on your phone. If it isn't, then you're out of luck unless you root your phone to bypass this restriction (either by spoofing the SKU, modifying the FeliCa configuration file, or patching the PixelNfc app). Or, you buy a new, Japan-specific version of your phone.
As for why this limitation exists, I don't really know. Sony apparently has patents/earns licensing income from the use of FeliCa chips, so that could be one reason. This isn't an issue for iPhone, as any iPhone you buy can use Osaifu-Keitai, but it is an issue with many Android devices and is why Japan-specific SKUs for many phones exist.
For more info on this mod/issue, check out this great GitHub page by user kormax (which is where the screenshots come from). Also check out this AOSP document: Host Card Emulation of FeliCa.
(2/2)
As for why this limitation exists, I don't really know. Sony apparently has patents/earns licensing income from the use of FeliCa chips, so that could be one reason. This isn't an issue for iPhone, as any iPhone you buy can use Osaifu-Keitai, but it is an issue with many Android devices and is why Japan-specific SKUs for many phones exist.
For more info on this mod/issue, check out this great GitHub page by user kormax (which is where the screenshots come from). Also check out this AOSP document: Host Card Emulation of FeliCa.
(2/2)
GitHub
GitHub - kormax/osaifu-keitai-google-pixel: Enabling Osaifu-Keitai function on non-Japanese Google Pixel phones.
Enabling Osaifu-Keitai function on non-Japanese Google Pixel phones. - kormax/osaifu-keitai-google-pixel
🔥23👍7
FYI: A new beta version of Magisk is now available, most notably bringing the ability to extract boot images directly from payload.bin files. I've been using the otadump tool to extract partitions, so this will save me a step!
Magisk v26.2 changelog:
* [MagiskBoot] Support extracting boot image from payload.bin
* [MagiskBoot] Support cpio files containing character files
* [MagiskBoot] Support listing cpio content
* [MagiskBoot] Directly handle AVB 1.0 signing and verification without going through Java implementation
* [Daemon] Make daemon socket a fixed path in MAGISKTMP
* [resetprop] Support printing property context
* [resetprop] Support only printing persistent properties from storage
* [resetprop] Properly support setting persistent properties bypassing property_service
* [MagiskSU] Support
* [MagiskSU] Support switching mount namespace to PID with
* [MagiskPolicy] Fix patching extended permissions
* [MagiskPolicy] Support more syntax for extended permissions
* [MagiskPolicy] Support printing out the loaded sepolicy rules
* [App] Support patching boot image from ROM zips
* [App] Properly preserve boot.img when patching Samsung firmware with init_boot.img
Magisk is not just used by modders. It's also used by security researchers and, as I recently learned, even by SoC vendors like Rockchip LOL. Here's an official doc from Rockchip that shows how to install Magisk onto Rockchip devices on Android 9/10.
Magisk v26.2 changelog:
* [MagiskBoot] Support extracting boot image from payload.bin
* [MagiskBoot] Support cpio files containing character files
* [MagiskBoot] Support listing cpio content
* [MagiskBoot] Directly handle AVB 1.0 signing and verification without going through Java implementation
* [Daemon] Make daemon socket a fixed path in MAGISKTMP
* [resetprop] Support printing property context
* [resetprop] Support only printing persistent properties from storage
* [resetprop] Properly support setting persistent properties bypassing property_service
* [MagiskSU] Support
-g and -G options* [MagiskSU] Support switching mount namespace to PID with
-t* [MagiskPolicy] Fix patching extended permissions
* [MagiskPolicy] Support more syntax for extended permissions
* [MagiskPolicy] Support printing out the loaded sepolicy rules
* [App] Support patching boot image from ROM zips
* [App] Properly preserve boot.img when patching Samsung firmware with init_boot.img
Magisk is not just used by modders. It's also used by security researchers and, as I recently learned, even by SoC vendors like Rockchip LOL. Here's an official doc from Rockchip that shows how to install Magisk onto Rockchip devices on Android 9/10.
GitHub
Release Magisk v26.2 · topjohnwu/Magisk
[MagiskBoot] Support extracting boot image from payload.bin
[MagiskBoot] Support cpio files containing character files
[MagiskBoot] Support listing cpio content
[MagiskBoot] Directly handle AVB 1.0...
[MagiskBoot] Support cpio files containing character files
[MagiskBoot] Support listing cpio content
[MagiskBoot] Directly handle AVB 1.0...
👍41❤6
The Google Play Developer Distribution Agreement has been updated today (August 29, 2023). Here's what changed:
Section 4.9 deleted this sentence: "You may not use user information obtained via Google Play to sell or distribute Products outside of Google Play."
Section 7.1 has a new sentence that reads: "To the extent prohibited by applicable law, Google will not condition or otherwise withhold Promotions, featuring, or marketing, based on whether You prioritize distributing Your apps on Google Play before other Android app stores."
According to the email Google sent out, these changes will go into effect starting September 28, 2023 for existing developers and immediately for all new developer accounts created starting today.
Previous version (dated October 3, 2022). |Current version (dated August 29, 2023).
Section 4.9 deleted this sentence: "You may not use user information obtained via Google Play to sell or distribute Products outside of Google Play."
Section 7.1 has a new sentence that reads: "To the extent prohibited by applicable law, Google will not condition or otherwise withhold Promotions, featuring, or marketing, based on whether You prioritize distributing Your apps on Google Play before other Android app stores."
According to the email Google sent out, these changes will go into effect starting September 28, 2023 for existing developers and immediately for all new developer accounts created starting today.
Previous version (dated October 3, 2022). |Current version (dated August 29, 2023).
🤔11👍7
The 2023 Samsung Developer Conference has been announced! It'll take place on October 5, 2023 in San Francisco, and unlike last year, anyone can attend it!
At SDC 2023, Samsung will talk about its upcoming Android 14-based release (One UI 6), Bixby, SmartThings, and more.
Press release |Website
At SDC 2023, Samsung will talk about its upcoming Android 14-based release (One UI 6), Bixby, SmartThings, and more.
Press release |Website
❤19👍11🔥2