Related
Hello. I'm working on a custom device that is not on the market yet, and I am having issues getting it to work with Google Play. I have root access, so I was able to sideload GooglePlay.apk and GoogleServicesFramework.apk. However, I am forced to use Market Helper in order to download apps. I would like to bake in compatibility to the ROM itself, but am having issues.
I've tried modifying the build.prop to have dummy values for ro.product.{model,device,manufacturer}, as well as ro.hardware and ro.com.google.clientidbase. I feel like I'm close, but the device still fails to be accepted by Play without marker helper.
Any hints or advice are tremendously appreciated!
Sorry, can't help you with the problem.
But I am really interested in your custom device. Could you please tell us more about it?
Cool.
For those who encounter a similar problem, I will post the answer. Credit to (xkcd: Wisdom of the Ancients) for the idea.
edit: the policy of not posting outside links is really annoying. All links have the base: http: slash slash developer dot android dotcom , just add the relevant url and glue it together.
Anyway, here goes. Turns out the build.prop was not the limiting factor.
Explanation of the overall process:
- Developers create an app, and list certain features it depends on in the manifest.xml file located in the root of the apk. ( /guide/topics/manifest/uses-feature-element.html)
- When the Play Store is opened, a call is made to getSystemAvailableFeatures()
- This call is handled by an internal app called PackageManager - (/reference/android/content/pm/PackageManager.html)
-This app looks in /system/etc/permissions and parses the xml files to determine what hardware and software features the phone has. it then sends this list back to the play store. - see( /guide/practices/compatibility.html) and ( /google/play/filters.html )
- The play store then filters the apps, as per the links above.
How to modify this:
- What I’ve done is taken the files from /system/etc/permissions on a galaxy S2 Skyrocket (my personal device), and copied in all of them, without overwriting the already existing files. Now, google play works and allows the download of the same subset of apps as on the Skyrocket.
For those wondering how to include these files at compile time, here is the answer:
http://forum.xda-developers.com/showthread.php?t=2356046
Thank you all for the wonderful support you are giving this device. While am an expert tinkerer, I do not have the time or knowledge necessary to take this device to the level I desire without the help you all afford.
So, having said that, I recieved my refurb unit (rollback was not an option when I contacted customer support, and 13.4.5.3 broke many things for me, The native Kindle app was among them.), I was able to toss twrp on it and update to 13.4.5.2, root it, and trick it to near perfection. Yet, I hate having to jump through hoops to get to my amazon books, so I played around with adb logcat and xda searches, and stumbled upon this...
http://forum.xda-developers.com/showthread.php?t=1479858
izomiac found a way to make a link on the older Kindles. I tried it, and though it looks like there are only a few changes, it does not work out of the box.
I would like to create a link to my books library as well as links to individual books.
Code:
Action: com.amazon.kindle.otter.action.SHOW_BOOKS
Category: android.intent.category.HOME
fails with an error of
Code:
Action: com.amazon.kindle.otter.action.SHOW_BOOKS
Category: android.intent.category.HOME requires com.amazon.SHOW_CONTENT_LIBRARY
I am using QCustomShortcut to try this as launching the intent from shell did not work either.
Does anyone have any suggestions? I asked over in iziomac's thread too, but it is really old, and I did not know if anyone would even see it.
Incidentally, his code for linking to individual books works incredibly. That is an android level intent, so there is less which could go wrong.
Code:
android.intent.action.VIEW
Data: kindle://book/?action=open&book_id=AMZNID0/<bookid>/0/
He explains pretty clearly how to get the book id as well.
izomiac said:
All that you want to change in that data string is the escaped book_id field. You can extract the book's ID from any Amazon Kindle product page (go to Manage your Kindle on Amazon.com). So, the book ID in this example is: B002WB0XW0 and the URL of the product page is http://www.amazon.com/dp/B002WB0XW0 (plus some useless SEO keywords and tracking cruft I omitted).
Click to expand...
Click to collapse
Again, this is all Izomiac's work, not mine.
~Leko
Could you not edit the APK and manually add the missing permission it requires?
https://developer.android.com/guide/topics/security/permissions.html
Thanks. When using a shortcut created with that app, who calls for the intent?
Sent from my KFTHWI using Tapatalk
WARNING: This is not a place for you to come to say how great you think Chainfire is. I'm not calling his character into question, only his methodologies and the character of the outfit he sold out to (and I don't question the act of selling out, that's business, pays the bills, and puts kids through college). The debates about what people prefer and why are as old as the first software. And of course, I will not tell you what to do, no matter how much I disagree with you. If you UNDERSTAND what I have to say, then THIS software is for you. If you don't, you are probably better off with binaries.
The root situation on Android 5.x left a lot to be desired. There was basically just one distributor of a functional substitute user command (su), and it was binary. Recently, ownership of that binary and all of its history has become the property of a previously unknown legal entity called "Coding Code Mobile Technology LLC". While it was presented as a positive thing that that entity has a great involvement with android root control, this is actually a VERY frightening development.
The people at CCMT are no strangers to the root community. They have invested in, or own, a number of popular root apps (though I am not at liberty to disclose which ones) - chances are, you are running one of them right now. I believe SuperSU has found a good home there, and trust time will not prove me wrong.
Click to expand...
Click to collapse
There are precisely two motives I can imagine for buying up all the root control software for Android;
1) monetizing it, which is contrary to the user's best interests,
2) something very frightening and dangerous involving the potential exploitation of everybody's devices.
You don't know the owners, and they are distributing a binary, so who the heck knows WHAT is going on.
Now a few important considerations with respect to your security and privacy;
1) Obfuscated binary cannot be sanely audited.
2) Function of this binary depends on the ability to manipulate selinux policies on the fly, including RELOADING the policy altogether and replacing it with something possibly completely different. Frankly, I've never heard a single reason why this should be necessary.
3) While a root control application may give you nice audits over other software that is using its service, it can *EASILY* lie about what it is doing itself. It can delete logs, it can share root with other applications that they have made deals with, it can directly sell you out to spammers, etc.
That is WAY too dangerous, and not worth the risk.
Frankly, you are safer if you disable selinux AND nosuid, and just run the old style of root where you set a copy of sh as 6755. And that is FRIGHTENINGLY dangerous.
So not satisfied with this state of root, and especially now with a new unknown entity trying to control the world, we bring you the rebirth of the ORIGINAL Superuser:
https://github.com/phhusson/Superuser
https://github.com/lbdroid/AOSP-SU-PATCH (this one is mine)
From the history of THAT Superuser:
http://www.koushikdutta.com/2008/11/fixing-su-security-hole-on-modified.html
Yes, look at the Superuser repo above and see whose space it was forked from.
Note: This is a work in progress, but working VERY well.
Use my patch against AOSP to generate a new boot.img, which includes the su binary.
Features:
1) selinux ENFORCING,
2) sepolicy can NOT be reloaded.
3) It is NOT necessary (or recommended) to modify your system partition. You can run this with dm-verity!
The source code is all open for you to audit. We have a lot of plans for this, and welcome suggestions, bug reports, and patches.
UPDATE NOVEMBER 19: We have a new github organization to... "organize" contributions to all of the related projects. It is available at https://github.com/seSuperuser
UPDATE2 NOVEMBER 19: We have relicensed the code. All future contributions will now be protected under GPLv3.
*** Regarding the license change; according to both the FSF and the Apache Foundation, GPLv3 (but not GPLv2) is forward compatible with the Apache License 2.0, which is the license we are coming from. http://www.apache.org/licenses/GPL-compatibility.html . What this means, is that it is *ILLEGAL* for anyone to take any portion of the code that is contributed from this point onward, and use it in a closed source project. We do this in order to guarantee that this VITAL piece of software will remain available for EVERYONE in perpetuity.
Added binaries to my the repo at https://github.com/lbdroid/AOSP-SU-PATCH/tree/master/bin https://github.com/seSuperuser/AOSP-SU-PATCH/tree/master/bin
These are *TEST* binaries ONLY. Its pretty solid. If you're going to root, this is definitely the best way to do so.
The boot.img has dm-verity and forced crypto OFF.
The idea is NOT to use as daily driver, while I can make no warranties at all regarding the integrity of the software, I use it myself, as do others, and its pretty good.
What I would like, is to have a few lots of people try it out and report on whether things WORK, or NOT.
IF NOT, as many details as possible about what happened, in particular, the kernel audit "adb shell dmesg | grep audit". On non-*nix host platforms that lack the grep command, you'll probably have to have to add quotes like this in order to use android's grep: "adb shell 'dmesg | grep audit'".
How to try:
0) Starting with a CLEAN system.img, get rid of supersu and all of its tentacles if you have it installed, if it was there, it will invalidate the tests.
1) Install the Superuser.apk. Its just a regular untrusted android application. Yes, there is a security hole here, since we aren't (yet) authenticating the communications between the android application and the binaries, or validating the application by signature, or anything else that would prevent someone from writing a bad Superuser.apk. This is on the list of things to do.
2) fastboot flash boot shamu-6.0-boot.img
3) test everything you can think of to see if it works as expected.
Note: there are some significant visual glitches in the android application, but nothing that makes it unusable.[/quote] @craigacgomez has been working on fixing up the UI. Its really paying off!!!
How you can reproduce this YOURSELF, which we RECOMMEND if you feel like daily driving it (in addition, make sure that you UNDERSTAND everything it does before you decide to do that, you are responsible for yourself;
You can build it any way you like, but I do my android userspace work in eclipse, so that is what I'm going to reference. Import the project from phhusson's git, including SUBMODULES. Right click the Superuser project --> Android Tools --> add native support. The library name you choose is irrelevant, since it won't actually build that library. Right click project again --> Build configurations --> Build all. This will produce two binaries under "libs", placeholder (which we won't be using), and su. You need the su binary. Then right click project again --> run as --> android application. This will build Superuser.apk, install it, and launch it.
Next:
repo init -u https://android.googlesource.com/platform/manifest -b android-6.0.0_r1
repo sync
Then apply su.patch from my git repo.
UNFORTUNATELY, the repo command isn't smart enough to apply a patch that it created itself. That means that you are going to have to split up the patch into the individual projects and apply them separately to the different repositories. This isn't that hard of a step though, since there are only FOUR repositories I've modified... build/ (this just makes it possible to build with a recent linux distro that doesn't have an old enough version of openjdk by using oraclejdk1.7. The boot.img doesn't actually need the jdk to install anyway -- its just part of the checking stage, so its up to you.), device/moto/shamu/, external/sepolicy/, system/core/.
After applying the patches, copy the su binary you generated with eclipse into device/moto/shamu/
Then ". build/envsetup.sh; lunch aosp_shamu-userdebug; make bootimage". That should take a minute or two to complete and you will have a boot.img built from source in out/target/product/shamu/
NEW UPDATE!!!!
While I haven't yet gotten around to running a complete cleanup (very important family stuff takes priority), I *HAVE* managed to find a half hour to get on with the Android-N program. If anybody takes a peek at the AOSP-SU-PATCH repository on the AOSP-N branch, you should find some interesting things there.
One warning first though... I updated the patches to apply against the N source code, and then updated some more to actually compile, and compiled it all. BUT HAVE NOT HAD THE OPPORTUNITY TO TEST IT YET.
Nice thing you came up. Sounds awesome.
We should have an alternate to all LLC thing, no matter how much respect (I owe you Chainfire thing) we got for the man who created CF Root (since Galaxy S days) and SupeeSU.
wow, tyvm for this! Will definitely test for ya and let you know.
I already applied your patch, built my own binaries and the boot.img but won't have a chance to test anything until tomorrow. Would love to get this %100 working fine and yeah, will use this from here on out instead of supersu.
Thanks again and yeah, will post when I have something ^^
I will be following progress closely, as should others. Without something like this, many in the community may naively let a corporate entity control root access on their devices. This is extremely frightening, it may not happen right away but if you believe the an entity will not monetize or exploit the current situation I believe you are sadly mistaken.
I could be wrong, however, it's not a risk I will take lightly and no one else should either.
Thanks for this.
Nice work!! Will be following this thread closely.
Time for me to learn eclipse. And do a heck of a lot more reading.
Larzzzz82 said:
Time for me to learn eclipse. And do a heck of a lot more reading.
Click to expand...
Click to collapse
Just note that I use eclipse because I'm used to it. Its become the "old" way for android dev.
i just paid for superSU is this the same people?
TheLoverMan said:
i just paid for superSU is this the same people?
Click to expand...
Click to collapse
I'm not sure what you are asking... are you asking if I am in any way affiliated with supersu, then you probably failed to read the first post in this thread altogether.
Charging money for a binary blob to use root on your device is borderline criminal, and unquestionably immoral. I'm sorry to hear that they got something out of you.
This is pretty great. I'll be watching this as well.
Perhaps this is not the place to take the tangent but why does root behave as it does and not more similar to a standard linux distro? It seems like it would be much more secure to have a sudo function as opposed to an all encompassing root. I'll admit I'm not that familiar with the inner working of the android OS but off hand I can't think of any program that absolutely needs to be automatically granted root every time it wants to run (I'm sure there are but even in this case the power user could chown it to standard root).
Wouldn't it be much more secure if you had to go in to developer options (which are already hidden by default) and turn on the option for sudo. This would then require a sudo-user password (perhaps even different than the standard lock screen password). Need to run a adblock update? Enter the password. Need to run Titanium backup? Enter the password... etc. Much more secure than a push of "accept".
Sorry for off topic but it's always made me wonder and seems like it would be root done right (see how I tied that back to the topic ) If elevating programs/tasks to a superuser was more secure perhaps it would not need to be such an issue...
^ Some root functionality is just too common for a Linux like sudo password to be usable at all. I'll give 2 examples:
1. Since Lollipop Google disabled access to mobile network settings for third party apps. Now it's only possible with root. I have an app that together with Tasker automates my network changing. That network app needs root access EVERY time there is any changes to the connected network and when it wants to change the settings.
Phone connects to a different cell tower? Root needed to detect this and determine the mobile network status.
You can figure how many times this is required per day.
2. I use Greenify to force some misbehaving apps to sleep after the screen goes off. It needs to request root every time it wants to sleep one of those apps. In other words every time I use them, after my screen goes off and I turn it back on I'd be facing both my secure lockscreen and the sudo password.
There's are plenty of other apps that need to request root access on a regular basis. These were just a few examples. If you only need root for TiBu then a sudo password type of security measure would work. In my case all I'd be doing with my phone would be typing that password again and again.
Beyond what is said above, to my understanding... What "root" is is just a way to install the "su" binary to your phone, with a nice GUI to make it more friendly for phone/tablet use.
Being rooted, if memory serves, is being able to access and change any file in your root directory, at least that's a simplified way to see it. The SU app is a GUI that is mostly used to control the ability of apps to access and change the root directory.
Sent from my Nexus 6 using Tapatalk
Interesting thread. Thanks for your work....subscribed
doitright said:
There are precisely two motives I can imagine for buying up all the root control software for Android;
1) monetizing it, which is contrary to the user's best interests,
2) something very frightening and dangerous involving the potential exploitation of everybody's devices.
Click to expand...
Click to collapse
I would suggest that there is a third potential motive here - that having control over the "only" way of rooting Android devices might be attractive to Google.
I've read a few articles suggesting that they would prefer to prevent people from rooting their phones (partially so that they can monetise Android Pay - which requires a Trusted Computer Base, which means unrooted - as well as controlling Ad Blockers, which affect a revenue stream). I also suspect that only a tiny minority of Android users - and most of them are probably on here - actually root their devices.
Regardless of the motives, having a technological monoculture is never a good thing, especially when it is delivered as a binary owned by an unknown organisation.
(No disrespect to Chainfire - I have had many years of root access to my devices thanks to his efforts.)
scryan said:
Beyond what is said above, to my understanding... What "root" is is just a way to install the "su" binary to your phone, with a nice GUI to make it more friendly for phone/tablet use.
Click to expand...
Click to collapse
Not quite.
"root" is the *name* of a privileged user, with user id of 0.
The "su" command (short for substitute user), is used to substitute your current user for another user, but most particularly root.
Every application and many subsystems in Android are granted each their own user, which are very restrictive, hence the need to escalate to root to obtain necessary privileges.
Philip said:
I would suggest that there is a third potential motive here - that having control over the "only" way of rooting Android devices might be attractive to Google.
Click to expand...
Click to collapse
What does that have to do with the third party? I doubt very much that Google would appreciate the security of their users being compromised by a 3rd party.
urrgevo said:
Being rooted, if memory serves, is being able to access and change any file in your root directory, at least that's a simplified way to see it. The SU app is a GUI that is mostly used to control the ability of apps to access and change the root directory.
Click to expand...
Click to collapse
Nope. The root directory can be setup to be accessible by specific users just by applying the appropriate permissions to the files.
The root directory and root user are not specifically related.
doitright said:
What does that have to do with the third party? I doubt very much that Google would appreciate the security of their users being compromised by a 3rd party.
Click to expand...
Click to collapse
Because the "third party" might actually be Google (or an organisation funded by them).
---------- Post added at 15:05 ---------- Previous post was at 15:02 ----------
doitright said:
Every application and many subsystems in Android are granted each their own user, which are very restrictive, hence the need to escalate to root to obtain necessary privileges.
Click to expand...
Click to collapse
Shouldn't need to su to root to do this - that's what setuid and setgid are for.
Many of us don't have root and many of us also uninstalled may system apps, including Fire Launcher. That left us with some annoyances. One major annoyance was being kicked to the lock screen whenever we swiped away apps from the recent apps menu. Some people saw annoying flashes. Well this isn't quite a fix, but it pretty much takes care of the problem. You can now remove your lock screen completely and replace it at will and you do NOT need root access.
***WARNING: Touching any other settings on your tablet during this guide can cause a brick!!!***
1. Download and install Settings Database Editor.
2. Plug your tablet into your PC and open an ADB window. Enter the following:
Code:
adb shell pm grant by4a.setedit22 android.permission.WRITE_SECURE_SETTINGS
Step number 2 MUST be done in order for this to work.
3. Open Settings Database Editor and tap on the 'secure' tab at the top.
4. These settings are in alphabetical order. Scroll until you see:
Code:
"lockscreen_disabled" "0"
5. Change the 0 to a 1. DO NOT CHANGE ANYTHING ELSE
6. Close Settings Database Editor
Now turn off your screen. Now turn it back on. You are welcome! I have a few more tricks coming. Watch for some later!
IF THE ABOVE DOESN'T WORK, TO DISABLE LOCK SCREEN:
Code:
adb shell settings put secure lockscreen_disabled 1
ENABLE LOCK SCREEN:
Code:
adb shell settings put secure lockscreen_disabled 0
Both methods don´t work on my Fire HD10 2017.
tommes-d said:
Both methods don´t work on my Fire HD10 2017.
Click to expand...
Click to collapse
It worked almost instantly for me. Maybe wait a bit? Did you reboot? It won't work on every device. Doesn't work on my Galaxy S7.
Not working for me too (Fire HD 8 2016). Also, you've made a mistake: original setting name is "lockscreen.disabled" (dot, not an underscore).
sensboston said:
Not working for me too (Fire HD 8 2016). Also, you've made a mistake: original setting name is "lockscreen.disabled" (dot, not an underscore).
Click to expand...
Click to collapse
Disappointing. Today I got a good one though. I can't wait to get home and post a thread.
I know this isn't the correct forum for this but I tried this on a Fire 7 (2017) and it also does not seem to work.
is there an updated way to do this?
is there an updated way to do this?
edit: kindle fire 8 7th gen, confirmed not working.
Doesn't work on my Fire HD8. But while browsing through Settings Database Editor I have found something useful.
In the "Global Table" tab there's a setting called LOCKSCREEN_AD_ENABLED. Change the value from 1 to 0, save. Turn off screen, turn it on again --> ads are gone!
At least for a while...
Seems to be working on KFAUWI (Fire 7 7th Gen) on 5.4.0.0.
EDIT: Maybe it doesn't work with 5.4.0.1 and later?
It would be useful for those reporting success/failure to include not just device model, but fw version as well.
EDIT1: After some time playing around the system I have found out that by default it actually does not work, but if Global Table->"device_provisioned" = 0 then lock screen gets disabled, but serial number gets greyed out and developer options get disabled, while adb remains functional.
On 5.6.0.0 even change to "device_provisioned" did not disable the lock screen.
gabosius said:
Seems to be working on KFAUWI (Fire 7 7th Gen) on 5.4.0.0.
EDIT: Maybe it doesn't work with 5.4.0.1 and later?
It would be useful for those reporting success/failure to include not just device model, but fw version as well.
Click to expand...
Click to collapse
There are settings in the "private" class that override some of these lower ones, usually in favor their using their own software. I think most device stock settings are hidden for the purpose of favoring their own software. Though with Amazon, I scratch my head. Why spend the large amount of money, to install a high tech, customizable GPS system on devices, only to spend more money carelessly blocking your Access?
Sent from my Samsung Galaxy S4 using XDA Labs
DragonFire1024 said:
There are settings in the "private" class that override some of these lower ones, usually in favor their using their own software. I think most device stock settings are hidden for the purpose of favoring their own software. Though with Amazon, I scratch my head. Why spend the large amount of money, to install a high tech, customizable GPS system on devices, only to spend more money carelessly blocking your Access?
Sent from my Samsung Galaxy S4 using XDA Labs
Click to expand...
Click to collapse
That's fairly simple, the same goes for one of the iPhones (don't recall which gen exactly) which had two different models of radio chips, one of which did support LTE, but Apple decided to disable LTE support for that gen of the phone altogether.
Now more on the topic, checked the specs of all 7th gen tablets, indeed none of them seem to support GPS officially (for some reason I thought that HD8/HD10 might have it), but if they have the hw, it could be for testing purposes to test proprietary GPS related sw on development devices before introducing it in the next gen? Or simply they decided to drop it somewhere along the way but left the hardware (as we still have Serial/UART on some production devices nowadays, which are used only for debugging in the development stage).
On the other hand, where did you get the info that it actually has GPS related hardware? Because while exploring my device settings I only found a hint on A-GPS support (which is not proven).
gabosius said:
That's fairly simple, the same goes for one of the iPhones (don't recall which gen exactly) which had two different models of radio chips, one of which did support LTE, but Apple decided to disable LTE support for that gen of the phone altogether.
Now more on the topic, checked the specs of all 7th gen tablets, indeed none of them seem to support GPS officially (for some reason I thought that HD8/HD10 might have it), but if they have the hw, it could be for testing purposes to test proprietary GPS related sw on development devices before introducing it in the next gen? Or simply they decided to drop it somewhere along the way but left the hardware (as we still have Serial/UART on some production devices nowadays, which are used only for debugging in the development stage).
On the other hand, where did you get the info that it actually has GPS related hardware? Because while exploring my device settings I only found a hint on A-GPS support (which is not proven).
Click to expand...
Click to collapse
Add a few .xml configuration files to start and there is configuration settings in the framework. Look for an app on the tablet with HERE in all caps in the title. That's the APK module making it possible. And yes I figured out a way to modify framework settings
DragonFire1024 said:
Add a few .xml configuration files to start and there is configuration settings in the framework. Look for an app on the tablet with HERE in all caps in the title. That's the APK module making it possible. And yes I figured out a way to modify framework settings
Click to expand...
Click to collapse
I see, just checked MT8127 specs, and indeed there seems to be integrated support for GPS with GLONASS, that may be something interesting to play with.
EDIT: HD8/HD10 even have broader support of GPS related technologies according to their SoC specs.
Yeah, I was following root progress thread, even tried Blueborne exploit (the one published by Armis labs on github) on KFAUWI without much success as there is no access to /proc/<pid>/maps. And framework-res.apk mod looks promising only for devices having root, as getting required permissions outside /system is rather problematic.
Yet I was surprised that WRITE_SECURE_SETTINGS can be assigned outside /system. As I was poking around com.amazon.dcp.permission.DISPLAY_DEBUG_UI for quite some time.
gabosius said:
Yet I was surprised that WRITE_SECURE_SETTINGS can be assigned outside /system. As I was poking around com.amazon.dcp.permission.DISPLAY_DEBUG_UI for quite some time.
Click to expand...
Click to collapse
Do you have any idea if you can grant something like Activity Launcher the DISPLAY_DEBUG_UI permission? Some of the activities gave me errors when I tried to open them, saying they require com.amazon.dcp.permission.DISPLAY_DEBUG_UI.
The thing is, this appears to be a custom permission added by Amazon, not available in the official Android documentation.
Would Activity Launcher even be capable of launching certain "hidden" activities with this permission granted? Presumably you would grant permission over ADB the same way as WRITE_SECURE_SETTINGS?
Any ideas would be great.
lakitu47 said:
Do you have any idea if you can grant something like Activity Launcher the DISPLAY_DEBUG_UI permission? Some of the activities gave me errors when I tried to open them, saying they require com.amazon.dcp.permission.DISPLAY_DEBUG_UI.
The thing is, this appears to be a custom permission added by Amazon, not available in the official Android documentation.
Would Activity Launcher even be capable of launching certain "hidden" activities with this permission granted? Presumably you would grant permission over ADB the same way as WRITE_SECURE_SETTINGS?
Any ideas would be great.
Click to expand...
Click to collapse
Tried granting it to other apps and it resulted in "com.amazon.dcp.permission.DISPLAY_DEBUG_UI is not a changeable type" the command I used was pm grant com.amazon.dcp com.amazon.dcp.permission.DISPLAY_DEBUG_UI so yes, the syntax is the same with custom amazon permissions. Also execution of dumpsys package com.amazon.dcp shows that app already has DISPLAY_DEBUG_UI permission.
My guess is that it requires root, as even when I am launching activity from adb shell (not in context of activity manager) I get the same error that it requires the permission, and the same goes for some other hidden amazon applications.
EDIT: you can get list of device permissions by executing "pm list permissions" without quotes from adb shell, there are at least a few interesting ones.
lakitu47 said:
Do you have any idea if you can grant something like Activity Launcher the DISPLAY_DEBUG_UI permission? Some of the activities gave me errors when I tried to open them, saying they require com.amazon.dcp.permission.DISPLAY_DEBUG_UI.
The thing is, this appears to be a custom permission added by Amazon, not available in the official Android documentation.
Would Activity Launcher even be capable of launching certain "hidden" activities with this permission granted? Presumably you would grant permission over ADB the same way as WRITE_SECURE_SETTINGS?
Any ideas would be great.
Click to expand...
Click to collapse
That's a great question and one that hasn't been asked before. I can tell you I've been able to, in some apps, modify the manifest permissions. For example, I can use an app to edit the manifest of Jack Pals terminal emulator to add the secure settings permission and have it successfully install etc. I never thought of doing the same with activity launcher and if successful, seeing what happens. This could be very interesting. If you give me a few copies of some of the manifests permissions, I can see if a recompile and install will hold.
DragonFire1024 said:
That's a great question and one that hasn't been asked before. I can tell you I've been able to, in some apps, modify the manifest permissions. For example, I can use an app to edit the manifest of Jack Pals terminal emulator to add the secure settings permission and have it successfully install etc. I never thought of doing the same with activity launcher and if successful, seeing what happens. This could be very interesting. If you give me a few copies of some of the manifests permissions, I can see if a recompile and install will hold.
Click to expand...
Click to collapse
I attached a text document with ALL of the permissions listed by "pm list permissions" since it was too long to put here.
lakitu47 said:
I attached a text document with ALL of the permissions listed by "pm list permissions" since it was too long to put here.
Click to expand...
Click to collapse
Give me a few hours to see if I can modify the app. If I can, I'll upload a. APK
Sent from my Samsung Galaxy S4 using XDA Labs
DragonFire1024 said:
Give me a few hours to see if I can modify the app. If I can, I'll upload a. APK
Sent from my Samsung Galaxy S4 using XDA Labs
Click to expand...
Click to collapse
Questionable whether anything would change, as I don't see where activity launcher would need write secure settings permission.
On the other hand I did some digging on the "not a changeable permission type" message, and this provides some answer on what it might be expecting in order to activate?/assign the permission.
gabosius said:
Questionable whether anything would change, as I don't see where activity launcher would need write secure settings permission.
On the other hand I did some digging on the "not a changeable permission type" message, and this provides some answer on what it might be expecting in order to activate?/assign the permission.
Click to expand...
Click to collapse
Interesting. So each permission has a certain "protection" level?
Hello
Bought HD 2021, no ads version
In short:
1. Need to block the updates. How do I go about it? I have a router, so blocking the traffic to Amazon maybe?
2. I'd love to completely disconnect the tablet from Amazon. I wish to gain maximum intrussion on my privacy, so I'd love to get rid of Alexa etc. But if there's something which improves the chances of increasing compability with older apps installed from a pre-downloaded files, not from Google Play etc. I'd like that too. Basically "what would you do in the first place". Aside from the looks. I don't really care how my icons arrangement looks like or if I can get somewhere in 2 clicks instead of 3. Not sure if the launcher swap is for me then.
After spending some time googling, I found that there's no way to install LineageOS on this one. And people talk about bad 7.3.2.2 update. (I have 7.3.2.1)
So, please help a noob with some simple step-by-step advise on what should I do (no need to tell me the actual steps of each procedure, I can google, but keep in mind I'm a total noob to Android and PC-Android apps, so please don't use shortcuts which prelong my future googling by 1000x, thanks )
I just powered it on, checked the firmware version, and didn't connect the internet to it yet.
OK, so I needlessly worried after finding a 5 method list of removing the auto updates and comments about none working, and thought Toolbox is mainly for changing launchers.
To answer most of my questions:
- Toobox allows to disable the updates, has ALL the options nicely explained and you can just read through all the menu items to learn what to do and what's what. It allows to remove the spying Amazon crap (Alexa), allows to sideload apps without using any stores (not even google account required, I guess ), restores Google Play access and gives direct access to the filesysem for easy file transfer. Among other.
Awesome thing. I didn't finish using the Toolbox yet, but seems like I'll be able to use the tablet now.
I have a new question though. If my OS version is from 2021, and I don't want the new updates, what about security vulnerabilities? Am I now an easy target?
edit: Still have Alexa
Amazon Alexa is one service
and
Alexa - is the name of second service
Also, how do I disable the Google Assistant after replacing Alexa with it?
Lastly. I have only 1.3GB of 3GB RAM free? Or is this under developer settings in Android settings menu, not properly displayed?
Welcome here! I hope you'll take this discussion over to the Toolbox thread to benefit more readers:
[WINDOWS][TOOL]Fire Toolbox V30.2
Fire Toolbox V30.2 All-In-One Toolbox for Fire Tablets! The Fire Toolbox is a collection of useful ADB (Android Debug Bridge) tweaks that can be applied to Amazon's Fire Tablets. The Toolbox project aims to help users fully customize and...
forum.xda-developers.com