The original thread has become a support thread for "it worked" and "it didnt work!" comments on the update, but the real work to be done is figuring out how to make our own update.
So far what we know about it is that every file in the archive is signed by the following files located inside the archive in "/META-INF/":
Code:
CERT.RSA CERT.SF MANIFEST.MF
The signatures are as follows (from CERT.SF):
Code:
Name: system/framework/input.jar
SHA1-Digest: oTqRlwaIYFz8+J6HPaqPmPF05do=
and from MANIFEST.MF:
Code:
Name: system/framework/input.jar
SHA1-Digest: GMJobzU6jVv2U756Kjbt292GdEA=
Making changes to either of these files causes the update to fail, so these files must also be signed. From what was guessed in the other thread, this might be done through the CERT.RSA file (binary, I cant make anything of it).
Inside the archive is a boot.img and a radio.img which were tested by someone and said not to be standard .img files.
In "/META-INF/com/google/android/" is a file called update-script (also signed, cannot be edited) which has the step by step procedure to update the system with all the included components. Permissions are set, images are flashed and at the very beginning device name (and other info?) are compared to the current device causing it to either fail or install. (contents below):
Code:
assert getprop("ro.build.fingerprint") == "tmobile/kila/dream/trout:1.0/TC4-RC29
/115247:user/ota-rel-keys,release-keys" || getprop("ro.build.fingerprint") == "t
mobile/kila/dream/trout:1.0/TC4-RC28/114235:user/ota-rel-keys,release-keys" || g
etprop("ro.build.fingerprint") == "tmobile/kila/dream/trout:1.0/TC4-RC19/109652:
user/ota-rel-keys,release-keys" || getprop("ro.build.fingerprint") == "tmobile/k
ila/dream/trout:1.0/TC4-RC29/115247:user/ota-rel-keys,test-keys" || getprop("ro.
build.fingerprint") == "tmobile/kila/dream/trout:1.0/TC4-RC28/114235:user/ota-re
l-keys,test-keys" || getprop("ro.build.fingerprint") == "tmobile/kila/dream/trou
t:1.0/TC4-RC19/109652:user/ota-rel-keys,test-keys"
assert compatible_with("0.2") == "true"
assert getprop("ro.product.device") == "dream" || getprop("ro.build.product") ==
"dream"
assert getprop("ro.bootloader") == "0.95.0000"
format BOOT:
show_progress 0.1 0
write_radio_image PACKAGE:radio.img
show_progress 0.5 0
format SYSTEM:
copy_dir PACKAGE:system SYSTEM:
set_perm_recursive 0 0 0755 0644 SYSTEM:
set_perm_recursive 0 2000 0755 0755 SYSTEM:bin
symlink dumpstate SYSTEM:bin/dumpcrash
set_perm 0 3004 02755 SYSTEM:bin/ping
symlink toolbox SYSTEM:bin/dmesg
symlink toolbox SYSTEM:bin/df
symlink toolbox SYSTEM:bin/getevent
symlink toolbox SYSTEM:bin/getprop
symlink toolbox SYSTEM:bin/hd
symlink toolbox SYSTEM:bin/id
symlink toolbox SYSTEM:bin/ifconfig
symlink toolbox SYSTEM:bin/iftop
symlink toolbox SYSTEM:bin/insmod
symlink toolbox SYSTEM:bin/ioctl
symlink toolbox SYSTEM:bin/kill
symlink toolbox SYSTEM:bin/ln
symlink toolbox SYSTEM:bin/log
symlink toolbox SYSTEM:bin/ls
symlink toolbox SYSTEM:bin/lsmod
symlink toolbox SYSTEM:bin/mkdir
symlink toolbox SYSTEM:bin/mkdosfs
symlink toolbox SYSTEM:bin/mount
symlink toolbox SYSTEM:bin/mv
set_perm 0 3003 02755 SYSTEM:bin/netcfg
symlink toolbox SYSTEM:bin/netstat
symlink toolbox SYSTEM:bin/notify
symlink toolbox SYSTEM:bin/ps
symlink toolbox SYSTEM:bin/printenv
symlink toolbox SYSTEM:bin/reboot
symlink toolbox SYSTEM:bin/rm
symlink toolbox SYSTEM:bin/renice
symlink toolbox SYSTEM:bin/rmdir
symlink toolbox SYSTEM:bin/rmmod
symlink toolbox SYSTEM:bin/route
symlink toolbox SYSTEM:bin/schedtop
symlink toolbox SYSTEM:bin/sendevent
symlink toolbox SYSTEM:bin/setconsole
symlink toolbox SYSTEM:bin/setprop
symlink toolbox SYSTEM:bin/sleep
symlink toolbox SYSTEM:bin/smd
symlink toolbox SYSTEM:bin/start
symlink toolbox SYSTEM:bin/stop
symlink toolbox SYSTEM:bin/sync
symlink toolbox SYSTEM:bin/top
symlink toolbox SYSTEM:bin/umount
symlink toolbox SYSTEM:bin/vmstat
symlink toolbox SYSTEM:bin/watchprops
symlink toolbox SYSTEM:bin/wipe
symlink toolbox SYSTEM:bin/cat
symlink toolbox SYSTEM:bin/chmod
symlink toolbox SYSTEM:bin/cmp
symlink toolbox SYSTEM:bin/date
symlink toolbox SYSTEM:bin/dd
set_perm 1002 1002 0440 SYSTEM:etc/dbus.conf
set_perm 0 2000 0550 SYSTEM:etc/init.goldfish.sh
set_perm 1002 1002 0440 SYSTEM:etc/hcid.conf
set_perm 1014 2000 0550 SYSTEM:etc/dhcpcd/dhcpcd-run-hooks
show_progress 0.2 0
write_raw_image PACKAGE:boot.img BOOT:
show_progress 0.2 10
And last but certainly not least, Download links!!! W00tah:
Download: https://android.clients.google.com/updates/signed-kila-ota-115247-prereq.TC4-RC19+RC28.zip
**This download might need to be refreshed once or twice before it works. If you get 503 server error, try again, if it doesn't work after a while use the links below.
Rapidshare Download 1: http://rapidshare.com/files/159243313/signed-kila-ota-115247-prereq.TC4-RC19_RC28.zip
Rapidshare Download 2: http://rapidshare.com/files/159244738/signed-kila-ota-115247-prereq.TC4-RC19_RC28.zip.html
Rapidshare Download 3: http://rapidshare.com/files/159798803/signed-kila-ota-115247-prereq.TC4-RC19_RC28.zip.html
If anyone knows anything about the signing process or thinks they have an idea on how to bypass it, please share it. XDA-devs is known for exactly this, but it seems we are limited to a smaller number of devs than most WM devices usually get so every little bit helps here.
I think your onto something.(cant't let this thread fade)
Just throwing stuff out there.....
in either /etc or /system there is a "security" directory...i assumed it had to do with the ssl certificates, but maybe it deals with the verification of the signatures in the updates. I mean the verification has to be checked somewhere on the device, when i get reliable internet i will take a closer look at this and see what comes of it.
excellent post by the way dark, glad your around
edit: took a closer look at your post and then the security directory, they are definently related....now it's time to study up on SHA-Digest
It seems the signature file checks the sha1-digest signature againts the manifest file. The third file seems to be the signature in which the hash get compared to. A java jdk developer might know how to do this. There seems to be a way to do this with the sun jdk (this seesms to be the method used). We might be able to change signatures but a more permanent solution seems to be able to disable the check all together in the restoration utility.
afbcamaro said:
It seems the signature file checks the sha1-digest signature againts the manifest file. The third file seems to be the signature in which the hash get compared to. A java jdk developer might know how to do this. There seems to be a way to do this with the sun jdk (this seesms to be the method used). We might be able to change signatures but a more permanent solution seems to be able to disable the check all together in the restoration utility.
Click to expand...
Click to collapse
if we could just figure out how to bypass it once we could have the modified update disable the check......
First of all let me state I didnt figure any of this out on my own. I basically gathered it all from 4 different threads (most on page 3-12 already) that have gone off track.
Second, without having root and being able to make changes to the update utility, all of our hacking will have to be done in the file itself (the certificate, or the manifest etc) for now. Once we can make changes to it and flash it, then we can give ourselves root (or just replace the recovery flash stuff to not read the certificates.
Looking for the security key on the device will prove useless... the way SHA1 was designed was that you have 2 keys. A private key you must sign with... and a public key that you use to verify. You can't sign with the public key because it will be different. Now if you know of someone who can crack SHA1 that will be the only person who can help us. But as it looks Google signs all their stuff with the SHA1 algorythm which is one of the hardest to crack.
So now we need to take a google dev as a hostage. Somone round up the guns, someone else get the tape, ill distance myself from it so I have an alibi.
Darkrift said:
So now we need to take a google dev as a hostage. Somone round up the guns, someone else get the tape, ill distance myself from it so I have an alibi.
Click to expand...
Click to collapse
LOL... who will hire the PI to find out where he lives?
neoobs said:
Looking for the security key on the device will prove useless... the way SHA1 was designed was that you have 2 keys. A private key you must sign with... and a public key that you use to verify. You can't sign with the public key because it will be different. Now if you know of someone who can crack SHA1 that will be the only person who can help us. But as it looks Google signs all their stuff with the SHA1 algorythm which is one of the hardest to crack.
Click to expand...
Click to collapse
I think what we need to do is research the iPhone root file system hack. Since the G1's stack is linux-based (same as iPhone), there are probably some similarities. Not sure if this hack would require taking a physical dump of the ROM or not, but that's for the more technical people to decide.
You are right about SHA1. Google seems to have had some interest in keeping the T-Mobile G1 closed. LOL
Thats why I suggested that we should disable the security check before sha1 digest becomes an issue.
The Iphone hack is simplicity compared to this. Apple left the root access password in plain open sight. Looking back on it, it seems google is a heck of a lot more security minded than apple...Go figure.
If this phone is truly open then we should be able to ASK google what the root credentials are. Making this public on androidcommunity should twist googles arm enough.
your check this file?
\system\etc\ permission.xml
HTML:
<?xml version="1.0" encoding="utf-8"?>
<!--
/*
* Copyright (C) 2008 Google Inc.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
-->
<!-- This file is used to define the mappings between lower-level system
user and group IDs and the higher-level permission names managed
by the platform.
Be VERY careful when editing this file! Mistakes made here can open
big security holes.
-->
<permissions>
<!-- ================================================================== -->
<!-- ================================================================== -->
<!-- ================================================================== -->
<!-- The following tags are associating low-level group IDs with
permission names. By specifying such a mapping, you are saying
that any application process granted the given permission will
also be running with the given group ID attached to its process,
so it can perform any filesystem (read, write, execute) operations
allowed for that group. -->
<permission name="android.permission.BLUETOOTH_ADMIN" >
<group gid="net_bt_admin" />
</permission>
<permission name="android.permission.BLUETOOTH" >
<group gid="net_bt" />
</permission>
<permission name="android.permission.INTERNET" >
<group gid="inet" />
</permission>
<permission name="android.permission.CAMERA" >
<group gid="camera" />
</permission>
<permission name="android.permission.READ_LOGS" >
<group gid="log" />
</permission>
<!-- The group that /cache belongs to, linked to the permission
set on the applications that can access /cache -->
<permission name="android.permission.ACCESS_CACHE_FILESYSTEM" >
<group gid="cache" />
</permission>
<!-- RW permissions to any system resources owned by group 'diag'.
This is for carrier and manufacture diagnostics tools that must be
installable from the framework. Be careful. -->
<permission name="android.permission.DIAGNOSTIC" >
<group gid="input" />
<group gid="diag" />
</permission>
<!-- ================================================================== -->
<!-- ================================================================== -->
<!-- ================================================================== -->
<!-- The following tags are assigning high-level permissions to specific
user IDs. These are used to allow specific core system users to
perform the given operations with the higher-level framework. For
example, we give a wide variety of permissions to the shell user
since that is the user the adb shell runs under and developers and
others should have a fairly open environment in which to
interact with the system. -->
<!-- System tool permissions granted to the shell. -->
<assign-permission name="android.permission.GET_TASKS" uid="shell" />
<assign-permission name="android.permission.CHANGE_CONFIGURATION" uid="shell" />
<assign-permission name="android.permission.REORDER_TASKS" uid="shell" />
<assign-permission name="android.permission.SET_ANIMATION_SCALE" uid="shell" />
<assign-permission name="android.permission.SET_PREFERRED_APPLICATIONS" uid="shell" />
<assign-permission name="android.permission.WRITE_SETTINGS" uid="shell" />
<assign-permission name="android.permission.BROADCAST_STICKY" uid="shell" />
<!-- Development tool permissions granted to the shell. -->
<assign-permission name="android.permission.SET_DEBUG_APP" uid="shell" />
<assign-permission name="android.permission.SET_PROCESS_LIMIT" uid="shell" />
<assign-permission name="android.permission.SET_ALWAYS_FINISH" uid="shell" />
<assign-permission name="android.permission.DUMP" uid="shell" />
<assign-permission name="android.permission.SIGNAL_PERSISTENT_PROCESSES" uid="shell" />
<!-- Internal permissions granted to the shell. -->
<assign-permission name="android.permission.FORCE_BACK" uid="shell" />
<assign-permission name="android.permission.BATTERY_STATS" uid="shell" />
<assign-permission name="android.permission.INTERNAL_SYSTEM_WINDOW" uid="shell" />
<assign-permission name="android.permission.INJECT_EVENTS" uid="shell" />
<assign-permission name="android.permission.SET_ACTIVITY_WATCHER" uid="shell" />
<assign-permission name="android.permission.READ_INPUT_STATE" uid="shell" />
<assign-permission name="android.permission.SET_ORIENTATION" uid="shell" />
<assign-permission name="android.permission.INSTALL_PACKAGES" uid="shell" />
<assign-permission name="android.permission.CLEAR_APP_USER_DATA" uid="shell" />
<assign-permission name="android.permission.DELETE_CACHE_FILES" uid="shell" />
<assign-permission name="android.permission.DELETE_PACKAGES" uid="shell" />
<assign-permission name="android.permission.ACCESS_SURFACE_FLINGER" uid="shell" />
<assign-permission name="android.permission.READ_FRAME_BUFFER" uid="shell" />
<assign-permission name="android.permission.DEVICE_POWER" uid="shell" />
<assign-permission name="android.permission.MODIFY_AUDIO_SETTINGS" uid="media" />
<assign-permission name="android.permission.ACCESS_DRM" uid="media" />
<!-- This is a list of all the libraries available for application
code to link against. -->
<library name="com.google.android.maps"
file="/system/framework/com.google.android.maps.jar" />
<library name="com.google.android.gtalkservice"
file="/system/framework/com.google.android.gtalkservice.jar" />
<library name="android.awt"
file="/system/framework/android.awt.jar" />
<library name="android.test.runner"
file="/system/framework/android.test.runner.jar" />
</permissions>
satru said:
your check this file?
\system\etc\ permission.xml
Click to expand...
Click to collapse
Those are the permissions you can give your program. Sadly there isn't a root access permission... but you could give a program all those permissions and maybe we can find a way of getting root.
Does the diagnostic permission group give us access to anything interesting on the file system?
Re: diagnostic permission
Unfortunately, you can't give an app the diagnostic permission, it is limited to system apps. The installer just ignores that permission if you ask for it in the AndroidManifest.xml for one of your apps.
Anyone here know anything about reading .rsa files? if we could fake that file we might be able to get somewhere.
That is a certificate from RSA The Security Division of EMC2 of all the contents in the upgrade.zip file.
If we could read it, it would look like the one for web sites. For example, go to citibankonline.com and depending on your browser, check the certificate for that site.
They get those certificates from companies like Verisign or RSA to prove that their site is secure or belongs to the people they say it does.
Same goes for these files, all the files are cross checked between each other.
MANIFEST.MF and CERT.CF both verify the files by hash. CERT.RSA is the certificate that these files are legit and that all/some are protected/encrypted with the private key from google.
We can't "fake" any of these files.
Methods for hacking never try this angle. It's always buffer overflows, securtiy holes, hardware hacks, etc. AFTER they get through, software hacks is easy because you can bypass the signature/certificate/private-public key checking or create our own keys.
Sha is hard to crack......but nowhere near the hardest...but as of now it is pretty much out of the realm of a realistic probability......
As for the IPhone kernel....I am assuming the iphone used an older kernel or something of the like that was vunerable to exploitation...as of now the kernel the android uses has no publicly available exploit
What I wonder is if we could get an exploitable app running? But probably still need somekind of root access
As afbcamaro pointed out, Apple put the root password out in the open.
Android doesn't even allow you to try to switch to root.
Honestly, exploitable app prob won't do it since the permissions are preset for app. Buffer overflow is proabably our best bet.
Speaking of, on the verbose log using addm (not sure, not at my computer) in the boot process, Bubble bash gets a error. Soon as I get to my computer I'll paste the error. Just wondering if anyone who might know, know if we might exploit it.
As per Apples Mind the Device was never Intended for Applications, Jailbreaks Disk Access and so they might never had seriously looked at Kernel security. But as the community Jail Breaks allowed the Apps, Got the Shell Access later using Exploits. They Later on patched it.
Uploading Apples Firmware in Infineon chips is little bit easy also compared to Samsung NAND Ram and their Boot loaders.
Now who know There may be 1 or 100 Exploits in Android also. That only will prove that.
Hi there folks,
I have an app (no source code) that I reverse engineered to get the code using the APKTOOOL
now the problem I'm having is that when trying to scan Bluetooth the app crashes and shuts down,
I managed to get it to scan once before to find the device
now if it DOESNT scan the app works fine
connects to the device and works fine
the issue is with it scanning
I changed a couple of permissions but still a no go
and in the developer studio it throws up A LOT or errors
below is a snippet from the XML file
please help me out folks
<uses-permission android:name="android.permission.BLUETOOTH"/>
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN"/>
<uses-permission android:name="android.permission.VIBRATE"/>
<uses-permission android:name="android.permission.ACCESS_FIND_LOCATION"/>
<uses-permission android:name="android.permission.ACCESS_WIFI_STATE"/>
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>
<uses-permission android:name="android.permission.CHANGE_WIFI_STATE"/>
<uses-permission android:name="android.permission.INTERNET"/>
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
<uses-permission android:name="android.permission.WAKE_LOCK"/>
<uses-permission android:name="android.permission.GET_TASKS"/>
Click to expand...
Click to collapse
Hello Good day, I don't know why it happened while I was coding, but I started getting an error in the AndroidManifest.xlm partition. It has deteriorated by itself, what I did, I could not fix the error.
! I'm writing with Kotlin!
Warnings I got into the registry;
Code:
2021-03-09 22:18:33,208 [ 16686] INFO - ule.android.SdkModuleSetupStep - Set Android SDK 'Android API 30 Platform' (C:/SDK) to module 'app'
2021-03-09 22:18:33,229 [ 16707] WARN - .issues.SyncIssueUsageReporter - Unknown sync issue type: 0
2021-03-09 22:18:33,232 [ 16710] WARN - .issues.SyncIssueUsageReporter - Unknown sync issue type: 0
2021-03-09 22:18:33,337 [ 16815] INFO - pl.ProjectRootManagerComponent - project roots have changed
2021-03-09 22:18:33,339 [ 16817] INFO - testKnownPluginVersionProvider - 'gradle' plugin missing from the offline Maven repo, will use default 4.0.0
2021-03-09 22:18:33,340 [ 16818] INFO - .MemorySettingsPostSyncChecker - 64bits? : true, current: 1280, available RAM: 16333
2021-03-09 22:18:33,340 [ 16818] INFO - s.MemorySettingsRecommendation - recommendation based on machine: 3072, on project: 1280
2021-03-09 22:18:33,342 [ 16820] INFO - s.plugins.gradle.GradleManager - Instructing gradle to use java from C:/Program Files/Android/Android Studio/jre
2021-03-09 22:18:33,347 [ 16825] WARN - e.project.sync.GradleSyncState - Gradle sync failed: Sync issues found (9 s 305 ms)
2021-03-09 22:18:33,347 [ 16825] WARN - e.project.sync.GradleSyncState - Sync issues found
java.lang.RuntimeException: Sync issues found
AndroidManifest.xml
XML:
<<<<<<< Original
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.rs.mobilbanka">
<!--
The ACCESS_COARSE/FINE_LOCATION permissions are not required to use
Google Maps Android API v2, but you must specify either coarse or fine
location permissions for the "MyLocation" functionality.
-->
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-permission android:name="android.permission.INTERNET"/>
<application
android:allowBackup="true"
android:icon="@mipmap/ic_launcher"
android:label="@string/app_name"
android:roundIcon="@mipmap/ic_launcher_round"
android:supportsRtl="true"
android:theme="@style/Theme.AppCompat.Light.NoActionBar">
<activity android:name=".profilemenu"></activity>
<!--
The API key for Google Maps-based APIs is defined as a string resource.
(See the file "res/values/google_maps_api.xml").
Note that the API key is linked to the encryption key used to sign the APK.
You need a different API key for each encryption key, including the release key that is used to
sign the APK for publishing.
You can define the keys for the debug and release targets in src/debug/ and src/release/.
-->
<meta-data
android:name="com.google.android.geo.API_KEY"
android:value="@string/google_maps_key" />
<activity
android:name=".subeveatm"
android:label="@string/title_activity_subeveatm" />
<activity
android:name=".anamenu"
android:label="@string/title_activity_anamenu" />
<activity
android:name=".MainActivity"
android:label="@string/title_activity_main2" />
<activity
android:name=".anamenu"
android:label="@string/title_activity_ana_menu" />
<activity
android:name=".anamenu"
android:label="@string/title_activity_ana_menu" />
<activity android:name=".login2" />
<activity android:name=".MainActivity">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
</application>
</manifest>
=======
<manifest xmlns:android ="http://schemas.android.com/apk/res/android">
<application>
<activity android:name ="com.rs.mobilbanka.Planlicalisma"
>
</activity>
</application>
</manifest>
>>>>>>> Added
Build gradle module section;
Code:
android {
compileSdkVersion 30
buildToolsVersion "30.0.3"
defaultConfig {
applicationId "com.rs.mobilbanka"
minSdkVersion 16
targetSdkVersion 30
versionCode 1
versionName "1.0"
testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
}
}
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
}
kotlinOptions {
jvmTarget = '1.8'
}
}
Code:
dependencies {
implementation fileTree(dir: "libs", include: ["*.jar"])
implementation "org.jetbrains.kotlin:kotlin-stdlib:$kotlin_version"
implementation 'androidx.core:core-ktx:1.3.2'
implementation 'androidx.appcompat:appcompat:1.2.0'
implementation 'androidx.constraintlayout:constraintlayout:2.0.4'
implementation 'com.google.android.material:material:1.3.0'
implementation 'androidx.vectordrawable:vectordrawable:1.1.0'
implementation 'androidx.navigation:navigation-fragment:2.3.3'
implementation 'androidx.navigation:navigation-ui:2.3.3'
implementation 'androidx.lifecycle:lifecycle-extensions:2.2.0'
implementation 'androidx.navigation:navigation-fragment-ktx:2.3.3'
implementation 'androidx.navigation:navigation-ui-ktx:2.3.3'
implementation 'com.google.android.gms:play-services-maps:17.0.0'
testImplementation 'junit:junit:4.12'
androidTestImplementation 'androidx.test.ext:junit:1.1.2'
androidTestImplementation 'androidx.test.espresso:espresso-core:3.3.0'
}
i've an old Android app "com.example.package" that works fine until on Android 9, on Android 10 i've never tested, but on Android 11 & 12 no longer work
this app - on first launch after installation - needs to download additional data on "/storage/emulated/0/Android/data/com.example.package/files/", but on Android 11 & 12 - get this error while starting additional data download:
Download stopped
com.example.androidlib.j: Could not create the directory /storage/emulated/0/Android/data/com.example.package/files/
with last ApkTool v2.7.0 java version (.jar) (tested also with last APK Editor on Android) i've decompiled APK file, and this is stock AndroidManifest.xml:
XML:
<?xml version="1.0" encoding="utf-8" standalone="no"?><manifest xmlns:android="http://schemas.android.com/apk/res/android" android:installLocation="preferExternal" package="com.example.package" platformBuildVersionCode="9" platformBuildVersionName="2.3.1">
<uses-permission android:name="android.permission.INTERNET"/>
<uses-permission android:name="android.permission.CHANGE_WIFI_MULTICAST_STATE"/>
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
<uses-permission android:name="com.android.vending.BILLING"/>
<supports-screens android:anyDensity="true" android:largeScreens="true" android:normalScreens="true" android:smallScreens="false" android:xlargeScreens="true"/>
<uses-configuration android:reqTouchScreen="finger"/>
<uses-feature android:name="android.hardware.sensor.accelerometer" android:required="true"/>
<uses-feature android:name="android.hardware.touchscreen.multitouch" android:required="true"/>
<uses-feature android:name="android.hardware.wifi" android:required="false"/>
<application android:icon="@drawable/icon" android:label="@string/app_name" android:theme="@android:style/Theme.Black.NoTitleBar.Fullscreen">
<activity android:configChanges="keyboardHidden|orientation" android:label="@string/app_name" android:name=".packageActivity" android:screenOrientation="landscape">
<intent-filter>
<action android:name="android.intent.action.MAIN"/>
<category android:name="android.intent.category.LAUNCHER"/>
</intent-filter>
</activity>
<activity android:configChanges="keyboardHidden|orientation" android:name="com.example.androidlib.MainActivity" android:screenOrientation="landscape"/>
<activity android:configChanges="keyboardHidden|orientation" android:name="com.example.androidlib.LicenseActivity" android:screenOrientation="landscape"/>
<activity android:configChanges="keyboardHidden|orientation" android:name="com.example.androidlib.DownloadActivity" android:screenOrientation="landscape"/>
<activity android:configChanges="keyboardHidden|orientation" android:name="com.example.androidlib.GLExtensionActivity" android:screenOrientation="landscape"/>
</application>
</manifest>
i tried to fix permission & build version issues with this strings:
platformBuildVersionCode="31" platformBuildVersionName="12"
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/>
<uses-permission android:name="android.permission.MANAGE_EXTERNAL_STORAGE"/>
and finally i've recompiled all with same last ApkTool v2.7.0 java version (.jar) (tested also with last APK Editor on Android)
but unfortunately, persist the error while starting additional data download
not work even if manually move additional data on right path/folder
how to solve?!?
To give users more control over their files and limit file clutter, Android 10 introduced a new storage paradigm for apps called scoped storage. Scoped storage changes the way apps store and access files on a device's external storage.
Therefore, for your app problems, in order to adapt to Android 10 and later, I recommend that you open the app project in Android Studio, make corresponding modifications of the source code, and rebuild and generate a new apk.